Re: replacing role-level NOINHERIT with a grant-level option

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: replacing role-level NOINHERIT with a grant-level option
Дата
Msg-id CAKFQuwa5YxEHqv-xu4__A5fv=+aL59vZquYjFiahudwT6pfsuw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: replacing role-level NOINHERIT with a grant-level option  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: replacing role-level NOINHERIT with a grant-level option  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jun 13, 2022 at 11:01 AM Robert Haas <robertmhaas@gmail.com> wrote:
Some
syntax would be a bit different on the new releases and that would
unlock some new options we don't currently have, but there's no
behavior that you can get today which you wouldn't be able to get any
more under this proposal.

Agreed.  Moving the inherit flag to the many-to-many join relation provides flexibility, while representing the present behavior is trivial - every row for a given member role has the same value for said flag.

One seemingly missing feature is to specify for a role that its privileges cannot be inherited.  In this case associations where it is the group role mustn't be flagged inherit.  Symmetrically, "inherit only" seems like a plausible option for pre-defined group roles.

I agree that granting membership makes the pg_auth_members record appear and revoking membership makes it disappear.

I dislike having GRANT do stuff when membership is already established.

ALTER MEMBER role IN group ALTER [SET | ASSUME] [TO | =] [TRUE | FALSE]

David J.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: better page-level checksums
Следующее
От: Robert Haas
Дата:
Сообщение: Re: replacing role-level NOINHERIT with a grant-level option