Horton
Menu

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Joe Conway <mail@joeconway.com>, "Bossart, Nathan" <bossartn@amazon.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-07-01T02:21:53Z
Lists: pgsql-hackers 
On Thu, Jun 30, 2022 at 7:29 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> IIUC you are suggesting that we'd leave rolinherit in pg_authid alone, but
> we'd add the ability to specify a grant-level option that would always take
> precedence.  The default (WITH INHERIT DEFAULT) would cause things to work
> exactly as they do today (i.e., use rolinherit).  Does this sound right?

Yeah, that could be an alternative to the patch I proposed previously.
What do you (and others) think of that idea?

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

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.