Re: REVOKE [ADMIN OPTION FOR] ROLE - Mailing list pgsql-hackers

From Egor Rogov
Subject Re: REVOKE [ADMIN OPTION FOR] ROLE
Date
Msg-id 55B62943.8020206@postgrespro.ru
Whole thread Raw
In response to Re: REVOKE [ADMIN OPTION FOR] ROLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: REVOKE [ADMIN OPTION FOR] ROLE
List pgsql-hackers
> 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.

Thanks,
Egor Rogov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Attachment

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: 9.5a1 BUG FIX: pgbench negative latencies
Next
From: Michael Paquier
Date:
Subject: Re: creating extension including dependencies