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

From Nathan Bossart
Subject Re: replacing role-level NOINHERIT with a grant-level option
Date
Msg-id 20220701025830.GA369935@nathanxps13
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
List pgsql-hackers
On Thu, Jun 30, 2022 at 10:21:53PM -0400, Robert Haas wrote:
> 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?

I like it.  If rolinherit is left in place, existing pg_dumpall scripts
will continue to work, and folks can continue to use the role-level option
exactly as they do today.  However, we'd be adding the ability to use a
grant-level option if desired, and it would be relatively easy to reason
about (i.e., the grant-level option always takes precedence over the
role-level option).  Also, AFAICT this strategy still provides the full set
of behavior that would be possible if only the grant-level option existed.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Backup command and functions can cause assertion failure and segmentation fault
Next
From: Isaac Morland
Date:
Subject: Re: pg_checkpointer is not a verb or verb phrase