Re: REVOKE [ADMIN OPTION FOR] ROLE
| От | Egor Rogov |
|---|---|
| Тема | Re: REVOKE [ADMIN OPTION FOR] ROLE |
| Дата | |
| Msg-id | [email protected] обсуждение исходный текст |
| Ответ на | Re: REVOKE [ADMIN OPTION FOR] ROLE (Robert Haas <[email protected]>) |
| Ответы |
Re: REVOKE [ADMIN OPTION FOR] ROLE
|
| Список | pgsql-hackers |
> On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov <[email protected]> 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
Вложения
В списке pgsql-hackers по дате отправления: