From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First draft of the PG 15 release notes |
Date: | 2022-07-01 18:08:00 |
Message-ID: | Yr84AO1O+zD6Sgot@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 29, 2022 at 10:08:08PM -0700, Noah Misch wrote:
> On Tue, Jun 28, 2022 at 04:35:45PM -0400, Bruce Momjian wrote:
> > > 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.
Thanks for the summary.
> > > > 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?
I see your point, that there is no indication of why you might not want
to restore the old permissions. I created the attached patch which
makes two additions to clarify this.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Attachment | Content-Type | Size |
---|---|---|
public.diff | text/x-diff | 937 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2022-07-01 18:12:52 | Re: oat_post_create expected behavior |
Previous Message | Alvaro Herrera | 2022-07-01 17:55:16 | Re: EINTR in ftruncate() |