From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ferdi Smit <FerdiSmit(at)optiver(dot)com>, Floris Van Nee <florisvannee(at)optiver(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: incorrect pg_dump output due to not handling dropped roles correctly |
Date: | 2020-01-29 19:46:45 |
Message-ID: | 32560.1580327205@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> In particular- should we really be setting default privileges for objects
> that are being created by an extension, at all? The more I think about it,
> the less I like it, particularly when we start to think about the trusted
> extension work that Tom’s doing.
> In short, I’m leaning towards the argument that this was a missing check in
> the default ACL code to explicitly *not* add default privileges on objects
> that are being created by an extension. With such a check, the entire
> wouldn’t end up in pg_init_privs and the issue that started this thread
> wouldn’t happen.
Hmm. I think we'd still wish pg_upgrade to preserve whatever privileges
have been granted on extension objects, but that doesn't necessarily
have to happen through pg_init_privs. I've forgotten the details ---
would the change you suggest be enough to make upgrade work correctly,
or would we need additional hacking?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-01-29 20:42:18 | Re: incorrect pg_dump output due to not handling dropped roles correctly |
Previous Message | Stephen Frost | 2020-01-29 19:07:25 | Re: incorrect pg_dump output due to not handling dropped roles correctly |