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

Reply via email to