public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Robert Haas <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Joe Conway <[email protected]>
Cc: Bossart, Nathan <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Date: Thu, 30 Jun 2022 16:29:31 -0700
Message-ID: <20220630232931.GA367181@nathanxps13> (raw)
In-Reply-To: <CA+Tgmobuqgr3XKujMwgsEZUxBHJA8jZSH2tVp7PC1cifePANtw@mail.gmail.com>
References: <CAGB+Vh4jWh-KuV6qt0FKC3M=HCZT1X=Kn5E1g68s1+0OSfoCdQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoYeNB1PxMO-TYv4_Ky7XR3-3Le+fpL87T7QMR=OWc7U1Q@mail.gmail.com>
<[email protected]>
<CA+Tgmoax3J2D1RoqSqBRuLVifMjinZ5SPvR+rBqBT89u57zOJQ@mail.gmail.com>
<[email protected]>
<CA+TgmoYmJtLA1aFF2dpGLuqWMuWwrf2SEoT-Ueqd4XCzLL61sA@mail.gmail.com>
<20220629231939.GA362451@nathanxps13>
<CA+Tgmobuqgr3XKujMwgsEZUxBHJA8jZSH2tVp7PC1cifePANtw@mail.gmail.com>
On Thu, Jun 30, 2022 at 09:42:11AM -0400, Robert Haas wrote:
> On Wed, Jun 29, 2022 at 7:19 PM Nathan Bossart <[email protected]> wrote:
>> I'm guessing we'll also need a new pg_dumpall option for generating pre-v16
>> style role commands versus the v16+ style ones. When run on v16 and later,
>> you'd have to require the latter option, as you won't always be able to
>> convert grant-level inheritance options into role-level options. However,
>> you can always do the reverse. I'm thinking that by default, pg_dumpall
>> would output the style of commands for the current server version.
>> pg_upgrade would make use of this option when upgrading from <v16 to v16
>> and above. Is this close to what you are thinking?
>
> I don't see why we need an option. pg_dump's charter is to produce
> output suitable for the server version that matches the pg_dump
> version. Existing pg_dump versions will do the right thing for the
> server versions they support, and in the v16, we can just straight up
> change the behavior to produce the syntax that v16 wants.
Got it. Makes sense.
>> > I suppose if we did it the second way, we could make the syntax GRANT
>> > granted_role TO recipient_role WITH INHERIT { TRUE | FALSE | DEFAULT
>> > }, and DEFAULT would copy the current value of the rolinherit
>> > property, so that changing the rolinherit property later would not
>> > affect previous grants. The reverse is also possible: with the same
>> > syntax, the rolinherit column could be changed from bool to "char",
>> > storing t/f/d, and 'd' could mean the value of the rolinherit property
>> > at time of use; thus, changing rolinherit would affect previous grants
>> > performed using WITH INHERIT DEFAULT but not those that specified WITH
>> > INHERIT TRUE or WITH INHERIT FALSE.
>>
>> Yeah, something like this might be a nice way to sidestep the issue. I was
>> imagining something more like your second option, but instead of continuing
>> to allow grant-level options to take effect when rolinherit was true or
>> false, I was thinking we would ignore them or even disallow them. By
>> disallowing grant-level options when a role-level option was set, we might
>> be able to avoid the confusion about what takes effect when. That being
>> said, the syntax for this sort of thing might not be the cleanest.
>
> I don't think that it's a good idea to disallow grant-level options
> when a role-level option is set, for two reasons. First, it would
> necessitate restricting the ability to ALTER the role-level option;
> otherwise no invariant could be maintained. Second, I'm interested in
> this feature because I want to be able to perform a role grant that
> will have a well-defined behavior without knowing what role-level
> options are set. I thought initially that I wouldn't be able to
> accomplish my goals if we kept the role-level options around, but now
> I think that's not true. However, I think I need the grant-level
> option to work regardless of how the role-level option is set. The
> problem with the role-level option is essentially that you can't
> reason about what a new grant will do.
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?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
view thread (74+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: replacing role-level NOINHERIT with a grant-level option
In-Reply-To: <20220630232931.GA367181@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox