On Thu, 2022-12-15 at 12:31 +0300, Pavel Luzanov wrote: > I think the approach that Nathan implemented [1] for TOAST tables > in the latest version can be used for partitioned tables as well. > Skipping the privilege check for partitions while working with > a partitioned table. In that case we would get exactly the same > behavior > as for INSERT, SELECT, etc privileges - the MAINTAIN privilege would > work for > the whole partitioned table, but not for individual partitions.
There is some weirdness in 15, too: create user foo; create user su superuser; grant all privileges on schema public to foo; \c - foo create table p(i int) partition by range (i); create index p_idx on p (i); create table p0 partition of p for values from (0) to (10); \c - su create table p1 partition of p for values from (10) to (20); \c - foo -- possibly weird because the 15 inserts into p1 (owned by su) insert into p values (5), (15); -- all these are as expected: select * from p; -- returns 5 & 15 insert into p1 values(16); -- permission denied select * from p1; -- permission denied -- the following commands seem inconsistent to me: vacuum p; -- skips p1 with warning analyze p; -- skips p1 with warning cluster p using p_idx; -- silently skips p1 reindex table p; -- reindexes p0 and p1 (owned by su) -- RLS is also bypassed \c - su grant select, insert on p1 to foo; alter table p1 enable row level security; create policy odd on p1 using (i % 2 = 1) with check (i % 2 = 1); \c - foo insert into p1 values (16); -- RLS error insert into p values (16); -- succeeds select * from p1; -- returns only 15 select * from p; -- returns 5, 15, 16 The proposal to skip privilege checks for partitions would be consistent with INSERT, SELECT, REINDEX that flow through to the underlying partitions regardless of permissions/ownership (and even RLS). It would be very minor behavior change on 15 for this weird case of superuser-owned partitions, but I doubt anyone would be relying on that. +1. I do have some lingering doubts about whether we should even allow inconsistent ownership/permissions. But I don't think we need to settle that question now. -- Jeff Davis PostgreSQL Contributor Team - AWS