On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Noah Misch (n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
