Re: PG 16 draft release notes ready

From: Noah Misch <noah(at)leadboat(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 16 draft release notes ready
Date: 2023-08-05 23:08:47
Message-ID: 20230805230847.GA1370050@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 18, 2023 at 04:49:47PM -0400, Bruce Momjian wrote:
> https://momjian.us/pgsql_docs/release-16.html

> <!--
> Author: Robert Haas <rhaas(at)postgresql(dot)org>
> 2023-01-10 [cf5eb37c5] Restrict the privileges of CREATEROLE users.
> -->
>
> <listitem>
> <para>
> Restrict the privileges of CREATEROLE roles (Robert Haas)
> </para>
>
> <para>
> Previously roles with CREATEROLE privileges could change many aspects of any non-superuser role. Such changes, including adding members, now require the role requesting the change to have ADMIN OPTION
> permission.
> </para>
> </listitem>
>
> <!--
> Author: Robert Haas <rhaas(at)postgresql(dot)org>
> 2023-01-24 [f1358ca52] Adjust interaction of CREATEROLE with role properties.
> -->
>
> <listitem>
> <para>
> Improve logic of CREATEROLE roles ability to control other roles (Robert Haas)
> </para>
>
> <para>
> For example, they can change the CREATEDB, REPLICATION, and BYPASSRLS properties only if they also have those permissions.
> </para>
> </listitem>

CREATEROLE is a radically different feature in v16. In v15-, it was an
almost-superuser. In v16, informally speaking, it can create and administer
its own collection of roles, but it can't administer roles outside its
collection or grant memberships or permissions not offered to itself. Hence,
let's move these two into the incompatibilities section. Let's also merge
them, since f1358ca52 is just doing to clauses like CREATEDB what cf5eb37c5
did to role memberships.

> <!--
> Author: Robert Haas <rhaas(at)postgresql(dot)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 WITH INHERIT and WITH ADMIN can now override this.
> </para>
> </listitem>
>
> <!--
> Author: Robert Haas <rhaas(at)postgresql(dot)org>
> 2023-01-10 [e5b8a4c09] Add new GUC createrole_self_grant.
> Author: Daniel Gustafsson <dgustafsson(at)postgresql(dot)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 (Robert Haas, 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.

> Remove libpq support for SCM credential authentication (Michael Paquier)

Since the point of removing it is the deep unlikelihood of anyone using it, I
wouldn't list this in "incompatibilities".

> Deprecate createuser option --role (Nathan Bossart)

This is indeed a deprecation, not a removal. By the definition of
"deprecate", it's not an incompatibility.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-08-06 02:01:14 Re: POC, WIP: OR-clause support for indexes
Previous Message Andres Freund 2023-08-05 22:26:39 Re: initdb caching during tests