Re: GRANT ON ALL IN schema
От | Pavel Stehule |
---|---|
Тема | Re: GRANT ON ALL IN schema |
Дата | |
Msg-id | 162867790908051304v45240d7aub0e4bccb6a6c8a1b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GRANT ON ALL IN schema (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2009/8/5 Tom Lane <tgl@sss.pgh.pa.us>: > 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. There are some people, that dislike stored procedures :(. Probably lot of MySQL users. For them are procedures devil still. I would to like some base maintenance library in plpgsql. But it's need plpgsql installed in core by default. Pavel > > 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 >
В списке pgsql-hackers по дате отправления: