Re: REVOKE [ADMIN OPTION FOR] ROLE
От | Egor Rogov |
---|---|
Тема | Re: REVOKE [ADMIN OPTION FOR] ROLE |
Дата | |
Msg-id | 55B62943.8020206@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: REVOKE [ADMIN OPTION FOR] ROLE (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: REVOKE [ADMIN OPTION FOR] ROLE
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: