Re: replacing role-level NOINHERIT with a grant-level option - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: replacing role-level NOINHERIT with a grant-level option
Date
Msg-id CAKFQuwa5YxEHqv-xu4__A5fv=+aL59vZquYjFiahudwT6pfsuw@mail.gmail.com
Whole thread Raw
In response to Re: replacing role-level NOINHERIT with a grant-level option  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: replacing role-level NOINHERIT with a grant-level option  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: better page-level checksums
Next
From: Robert Haas
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option