Robert Haas <robertmhaas@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
