On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Noah Misch (noah@leadboat.com) wrote:
>> > Updated patch attached. I'll give it another good look and then commit
>> > it, barring objections.
>>
>> This thread and its satellite[1] have worked their way through a few designs.
>> At first, it was adding role attributes, alongside existing attributes like
>> REPLICATION and BYPASSRLS. It switched[2] to making pg_dump preserve ACLs on
>> system objects. Built-in roles joined[3] the pg_dump work to offer predefined
>> collections of ACL grants. Finally, it dropped[4] the pg_dump side and
>> hard-coded the roles into the features they govern.
>
> Correct, after quite a bit of discussion and the conclusion that, while
> pg_dump support for dumping ACLs might be interesting, it was quite a
> bit more complex an approach than this use-case justified.
Hmm. I don't think I agree with that conclusion. Who were the
participants in that discussion, and how many people spoke in favor
from moving on from that proposal - which I rather liked - to what
you've got now? Do you have links to the relevant portion of the
relevant thread?
I think it's not a very good thing if we add roles that allow, say,
execution of exactly one SQL function. The
dump-grants-on-system-objects proposal would accomplish the same thing
in a much more flexible way, and with less catalog clutter. More
broadly, I'm not very convinced that even the roles which allow for
rights on multiple objects are going to meet with general approval.
There has been enough discussion of which roles should be created and
which things should be included in each one, and the overall tenor of
that discussion seems to be that different people have different
ideas. Under those circumstances, it seems very dubious to proceed
with this. Michael seems to think that we can go ahead and start
changing things and sort out whatever is broken later, but that
doesn't sound like a very good plan to me. We can change the
internals of a bad implementation later and replace it with a good
implementation, but changing user-visible behavior once people have
started relying on it is a lot harder.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company