On Sat, Aug 5, 2023 at 04:08:47PM -0700, Noah Misch wrote:
> > Author: Robert Haas <rhaas@postgresql.org>
> > 2022-08-25 [e3ce2de09] Allow grant-level control of role inheritance behavior.
> > -->
> >
> > <listitem>
> > <para>
> > Allow GRANT to control role inheritance behavior (Robert Haas)
> > </para>
> >
> > <para>
> > By default, role inheritance is controlled by the inheritance status of the member role. The new GRANT clauses
WITHINHERIT and WITH ADMIN can now override this.
> > </para>
> > </listitem>
> >
> > <!--
> > Author: Robert Haas <rhaas@postgresql.org>
> > 2023-01-10 [e5b8a4c09] Add new GUC createrole_self_grant.
> > Author: Daniel Gustafsson <dgustafsson@postgresql.org>
> > 2023-02-22 [e00bc6c92] doc: Add default value of createrole_self_grant
> > -->
> >
> > <listitem>
> > <para>
> > Allow roles that create other roles to automatically inherit the new role's rights or SET ROLE to the new role
(RobertHaas, Shi Yu)
> > </para>
> >
> > <para>
> > This is controlled by server variable createrole_self_grant.
> > </para>
> > </listitem>
>
> Similarly, v16 radically changes the CREATE ROLE ... WITH INHERIT clause. The
> clause used to "change the behavior of already-existing grants." Let's merge
> these two and move the combination to the incompatibilities section.
I need help with this. I don't understand how they can be combined, and
I don't understand the incompatibility text in commit e3ce2de09d:
If a GRANT does not specify WITH INHERIT, the behavior based on
whether the member role is marked INHERIT or NOINHERIT. This means
that if all roles are marked INHERIT or NOINHERIT before any role
grants are performed, the behavior is identical to what we had before;
otherwise, it's different, because ALTER ROLE [NO]INHERIT now only
changes the default behavior of future grants, and has no effect on
existing ones.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
