Re: First draft of the PG 15 release notes
От | Noah Misch |
---|---|
Тема | Re: First draft of the PG 15 release notes |
Дата | |
Msg-id | 20220630050808.GC2257984@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: First draft of the PG 15 release notes (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: First draft of the PG 15 release notes
(Bruce Momjian <bruce@momjian.us>)
|
Список | 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 по дате отправления:
Предыдущее
От: Noah MischДата:
Сообщение: Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)