From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | 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:07:25 |
Message-ID: | CAOuzzgqSoB3bAe8VcYPCvvk=pfBmLz4kmA5L8wGsTqPatuRg0w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Greetings,
On Fri, Jan 17, 2020 at 16:26 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
> Stephen, are you intending to get this bug fixed?
I had been hoping to get some kind of feedback or even a response regarding
to the email I posted about what’s going on and how we might want to think
about handling this situation.
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.
Thanks,
Stephen
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-29 19:46:45 | Re: incorrect pg_dump output due to not handling dropped roles correctly |
Previous Message | Kieran McCusker | 2020-01-29 15:31:05 | Re: BUG #16223: Performance regression between 11.6 and 12.1 in an SQL query with a recursive CTE based on function |