On 27.07.2015 22:09, Stephen Frost wrote:
* Egor Rogov (e.ro...@postgrespro.ru) wrote:
On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov <e.ro...@postgrespro.ru> wrote:
So, the question: is it a documentation bug (as it seems to me), code bug,
or I missed something?
Your analysis looks right to me, but I don't know whether the code or
the documentation should be changed. This claim was added by Tom Lane
in 2005 in commit 58d214e51fe50b10b4439da6ec263d54c155afbf. It might
be worth checking whether the claim was true at that time and later
became false, or whether it was never true to begin with.
As far as I can see, modern revoke syntax for revoking membership in
a role (along with "admin option") was introduced in commit 7762619
(by Tom Lane, 2005). Code for handling this command didn't pay
attention for "restrict/cascade" keywords then, as it does not now.
Before that, another syntax was in use: alter group groupname drop
user username [, ...]. It did not include notion of "cascade" at
all.
I guess that "revoke role_name from role_name" inherited
"[cascade|restrict]" section from general revoke command but never
actually used it. And I see no point in changing this, because role
membership is somewhat more static than privileges.
So I would propose the attached fix for documentation.
Have you looked at the SQL spec at all for this..? That's what we
really should be looking at to determine if this is a documentation
issue or a code issue.
I'll take a look in a day or two after I've caught up on other things,
if no one beats me to it.
Well, I looked into a draft of SQL:2003. It basically says that
"cascade" for <revoke role statement> must behave the same way as for
<revoke privilege statement>. That is, from standard's point of view we
have a code issue.
Still I doubt about usefulness of this behavior. Do we really need it in
PostgreSQL?
Thanks,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
