Robert Haas <robertmh...@gmail.com> writes: > I have one database that is set up with a reporting user (read only on > everything). It requires constant maintenance. Every time an object > is added or deleted (or dropped and recreated, like a view, which I do > ALL THE TIME to work around the inability to add/remove columns) the > permissions get shot to hell. I finally crontabbed a script that > fixes it every 20 minutes. I had another database where I tried to do > some real permission separation and it was just a huge pain in the > ass.
> Grant on all isn't gonna fix these problems completely, but it's a > start. The DefaultACL stuff is another important step in the right > direction. Seems like default ACLs, not grant-on-all, is what you want for that. The idea of better support for plpgsql-driven granting isn't going to compete with default ACLs, but it does compete with grant-on-all. So that's why I'm thinking we ought to take a harder look at that before adding nonstandard extensions to GRANT. Josh's position that "this should be standard SQL" is nonsense, or at least he ought to be making that argument to the standards committee not us. It *isn't* standard, and therefore it's up to us to decide how we want to expose the facility. What's more, syntax extensions to GRANT are a pretty risky way to do it: what if the SQL committee sees the light and SQL:201x includes a GRANT extension, only it conflicts with ours? If we want something built-in, maybe providing some prefab plpgsql functions is the way to go. But we'd have to arrive at a consensus on what best practice of that form looks like. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers