On 27.07.2015 22:09, Stephen Frost wrote:
> * Egor Rogov (e.rogov@postgrespro.ru) wrote:
>>> On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov <e.rogov@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