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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: tushar <tushar.ahuja@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.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-08-23T18:58:32Z
Lists: pgsql-hackers

Attachments

On Thu, Jul 28, 2022 at 12:32 PM tushar <tushar.ahuja@enterprisedb.com> wrote:
> On 7/28/22 8:03 PM, Robert Haas wrote:
> > No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ...
> > is intended to be a way of switching an option off.
> Ok, Thanks, Robert. I tested with a couple of more scenarios like
> pg_upgrade/pg_dumpall /grant/revoke .. with admin option/inherit
> and things look good to me.

This patch needed to be rebased pretty extensively after commit
ce6b672e4455820a0348214be0da1a024c3f619f. Here is a new version.

-- 
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.