Re: PG 16 draft release notes ready

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: PG 16 draft release notes ready
Дата
Msg-id 20230805230847.GA1370050@rfd.leadboat.com
обсуждение исходный текст
Ответ на PG 16 draft release notes ready  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: PG 16 draft release notes ready
Re: PG 16 draft release notes ready
Re: PG 16 draft release notes ready
Список 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@postgresql.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,
includingadding members, now require the role requesting the change to have ADMIN OPTION
 
> permission.
> </para>
> </listitem>
> 
> <!--
> Author: Robert Haas <rhaas@postgresql.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@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 WITH
INHERITand 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.

> 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: initdb caching during tests
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: POC, WIP: OR-clause support for indexes