Re: role self-revocation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: role self-revocation
Дата
Msg-id CA+Tgmob9+PLuhP2Bqfr9rde9_C+xoSxj6HyKm9s6nQ7syfJKPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: role self-revocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: role self-revocation  (Stephen Frost <sfrost@snowman.net>)
Re: role self-revocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Mar 9, 2022 at 4:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > In my opinion, the right to
> > administer a role - regardless of whether or not it is a login role -
> > most naturally vests in the role that created it, or something in that
> > direction at least, if not that exact thing.
>
> This seems like a reasonable answer to me too: the creating role has admin
> option implicitly, and can then choose to grant that to other roles.
> Obviously some work needs to be done to make that happen (and we should
> see whether the SQL spec has some different idea).

Well, the problem is that as far as I can see, the admin option is an
optional feature of membership. You can grant someone membership
without admin option, or with admin option, but you can't grant them
the admin option without membership, just like you can't purchase an
upgrade to first class without the underlying plane ticket. What would
the syntax look even like for this? GRANT foo TO bar WITH ADMIN OPTION
BUT WITHOUT MEMBERSHIP? Yikes.

But do we really have to solve this problem before we can clean up
this session exception? I hope not, because I think that's a much
bigger can of worms than this is.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: [Proposal] vacuumdb --schema only
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: role self-revocation