Re: First draft of the PG 15 release notes - Mailing list pgsql-hackers

From Noah Misch
Subject Re: First draft of the PG 15 release notes
Date
Msg-id 20220630050808.GC2257984@rfd.leadboat.com
Whole thread Raw
In response to Re: First draft of the PG 15 release notes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: First draft of the PG 15 release notes
List pgsql-hackers
On Tue, Jun 28, 2022 at 04:35:45PM -0400, Bruce Momjian wrote:
> On Mon, Jun 27, 2022 at 11:37:19PM -0700, Noah Misch wrote:
> > On Tue, May 10, 2022 at 11:44:15AM -0400, Bruce Momjian wrote:
> > > I have completed the first draft of the PG 15 release notes
> > 
> > > <!--
> > > Author: Noah Misch <noah@leadboat.com>
> > > 2021-09-09 [b073c3ccd] Revoke PUBLIC CREATE from public schema, now owned by pg
> > > -->
> > > 
> > >     <listitem>
> > >      <para>
> > >       Remove <literal>PUBLIC</literal> creation permission on the <link
> > >       linkend="ddl-schemas-public"><literal>public</literal> schema</link>
> > >       (Noah Misch)
> > >      </para>
> > > 
> > >      <para>
> > >       This is a change in the default for newly-created databases in
> > >       existing clusters and for new clusters;  <literal>USAGE</literal>
> > 
> > If you dump/reload an unmodified v14 template1 (as pg_dumpall and pg_upgrade
> > do), your v15 template1 will have a v14 ACL on its public schema.  At that
> > point, the fate of "newly-created databases in existing clusters" depends on
> > whether you clone template1 or template0.  Does any of that detail belong
> > here, or does the existing text suffice?
> 
> I think it is very confusing to have template0 have one value and
> template1 have a different one, but as I understand it template0 will
> only be used for pg_dump comparison, and that will keep template1 with
> the same permissions, so I guess it is okay.

It's an emergent property of two decisions.  In the interest of backward
compatibility, I decided to have v15 pg_dump emit GRANT for the public schema
even when the source is an unmodified v14- database.  When that combines with
the ancient decision that a pg_dumpall or pg_upgrade covers template1 but not
template0, one gets the above consequences.  I don't see a way to improve on
this outcome.

> > >       permissions on the <literal>public</literal> schema has not
> > >       been changed.  Databases restored from previous Postgres releases
> > >       will be restored with their current permissions.  Users wishing
> > >       to have the old permissions on new objects will need to grant
> > 
> > The phrase "old permissions on new objects" doesn't sound right to me, but I'm
> > not sure why.  I think you're aiming for the fact that this is just a default;
> > one can still change the ACL to anything, including to the old default.  If
> > these notes are going to mention the old default like they do so far, I think
> > they should also urge readers to understand
> > https://www.postgresql.org/docs/devel/ddl-schemas.html#DDL-SCHEMAS-PATTERNS
> > before returning to the old default.  What do you think?
> 
> Agreed, the new text is:
> 
>     Users wishing to have the former permissions will need to grant
>     <literal>CREATE</literal> permission for <literal>PUBLIC</literal> on
>     the <literal>public</literal> schema; this change can be made on
>     <literal>template1</literal> to cause all new databases to have these
>     permissions.

What do you think about the "should also urge readers ..." part of my message?



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)
Next
From: Dong Wook Lee
Date:
Subject: Re: doc: pg_prewarm add configuration example