On Sat, Jul 02, 2022 at 08:45:50AM -0400, Robert Haas wrote:
> I don't think there is a whole lot of point in replacing role-level
> flags with predefined roles that work exactly the same way. Maybe
> there is some point, but I'm not excited about it. The problem with
> these settings in my opinion is that they are too monolithic. Either
> you can create any role with basically any privileges or you can
> create no roles at all. Either you are a superuser and can bypass all
> permissions checks or you are not and can't bypass any permissions
> checks.
Okay. I see.
>> unparenthesized syntax or add WARNINGs when it is used?) For [NO]INHERIT
>> and WITH INHERIT DEFAULT, presumably we could do something similar. Down
>> the road, those would be removed in favor of only using grant-level
>> options.
>
> I think it'd be hard to do that if WITH INHERIT DEFAULT is actually
> state stored in the catalog. Maybe I should revise this again so that
> the catalog column is just true or false, and the role-level property
> only sets the default for future grants. That might be more like what
> Tom had in mind originally.
I was thinking that when DEFAULT was removed, pg_dump would just need to
generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older
versions. Using the role-level property as the default for future grants
seems a viable strategy, although it would break backward compatibility.
For example, if I create a NOINHERIT role, grant a bunch of roles to it,
and then change it to INHERIT, the role won't begin inheriting the
privileges of the roles it is a member of. Right now, it does.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
