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

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Joe Conway <mail@joeconway.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Bossart, Nathan" <bossartn@amazon.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-06-13T18:42:28Z
Lists: 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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix a bug in roles_is_member_of.

  2. docs: Fix up some out-of-date references to INHERIT/NOINHERIT.

  3. Allow grant-level control of role inheritance behavior.

  4. Make role grant system more consistent with other privileges.

  5. Document basebackup_to_shell.required_role.