But why should a superuser need the ACL to be applied before being allowed access? If you make the permission-checking function check if the user is a superuser before looking for per-user grants, wouldn't that solve the issue?
On 26 July 2017 at 16:30, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Instead, I've prepared the attached draft patch, which addresses the > >> problem by teaching pg_backup_archiver.c to process TOC entries in > >> three separate passes, "main" then ACLs then matview refreshes. > > > What worries me a bit is the possibility that something might depend > > on a matview having already been refreshed. I cannot immediately > > think of a case whether such a thing happens that you won't dismiss as > > wrong-headed, but how sure are we that none such will arise? > > Um, there are already precisely zero guarantees about that. pg_dump > has always been free to order these actions in any way that satisfies > the dependencies it knows about. > > It's certainly possible to break it by introducing hidden dependencies > within CHECK conditions. But that's always been true, with or without > materialized views, and we've always dismissed complaints about it with > "sorry, we won't support that". (I don't think the trigger case is > such a problem, because we restore data before creating any triggers.) > > Meanwhile, we have problems that bite people who aren't doing anything > stranger than having a matview owned by a non-superuser. How do you > propose to fix that without reordering pg_dump's actions? > > Lastly, the proposed patch has the advantage that it acts at the restore > stage, not when a dump is being prepared. Since it isn't affecting what > goes into dump archives, it doesn't tie our hands if we think of some > better idea later. > > regards, tom lane >
