Re: First draft of the PG 15 release notes

On Tue, May 10, 2022 at 04:02:35PM -0500, Justin Pryzby wrote:
> On Tue, May 10, 2022 at 04:18:10PM -0400, Bruce Momjian wrote:
> > > "separately" seems vague. Currently in v10-v13, extended stats are collected
> > > for partitioned tables, and collected for the "SELECT FROM ONLY"/parent case
> > > for inheritance parents. This changes to also collect stats for the "SELECT
> > > FROM tbl*" case. See also: 20220204214103(dot)GT23027(at)telsasoft(dot)com(dot)
> >
> > Agreed, reworded. Can you check you like my new wording?
>
> Now it says:
> | Allow extended statistics to record statistics for a parent with all it children (Tomas Vondra, Justin Pryzby)
>
> it should say "its" children.

Fixed.

> > > | Add function pg_settings_get_flags() to get the flags of server-side variables (Justin Pryzby)
> > >
> > > IMO this is the same, but I think maybe Michael things about it differently...
> >
> > Uh, I thought it might hvae user value as well as developer.
>
> The list of flags it includes is defined as "the flags we needed to deprecate
> ./check_guc", but it could conceivably be useful to someone else... But it
> seems more like allow_in_place_tablespaces; it could go into the "source code"
> section, or be removed.

Okay, I moved into source code.

> > > | When EXPLAIN references the temporary object schema, refer to it as "pg_temp" (Amul Sul)
> > > | When specifying fractional interval values in units greater than months, round to the nearest month (Bruce Momjian)
> > > | Limit support of psql to servers running PostgreSQL 9.2 and later (Tom Lane)
> > > | Limit support of pg_dump and pg_dumpall to servers running PostgreSQL 9.2 and later (Tom Lane)
> > > | Limit support of pg_upgrade to old servers running PostgreSQL 9.2 and later (Tom Lane)
> > > | Remove server support for old BASE_BACKUP command syntax and base backup protocol (Robert Haas)
> > >
> > > Do these need to be in the "compatibility" section ?
> >
> > Uh, I think of compatibility as breakage, while removing support for
> > something doesn't seem like breakage.
>
> I think removing support which breaks a user-facing behavior is presumptively a
> compatibility issue.

I moved the EXPLAIN and fractional interval items to the compatibility
section. I didn't change the psql and pg_dump items since they are
already in their own sections and are clearly support removal rather
than direct changes in behavior that would be expected. However, if
someone else feels they should be moved, I will move them, so someone
please reply if you feel that way.

> > I didn't think EXPLAIN changes were user-parsed, so no breakage?
>
> Why would we have explain(format json/xml) if it wasn't meant to be parsed ?
> At one point I was parsing its xml.
>
> I'll let other's comment about the rest of the list.

Good point on the formatted EXPLAIN output being affected, which is why
moving it does make sense.

> > > | Automatically export server variables using PGDLLIMPORT on Windows (Robert Haas)
> > >
> > > I don't think it's "automatic" ?
> >
> > Yes, reworded.
>
> Maybe it's a tiny bit better to say:
> | Export all server variables on Windows using PGDLLIMPORT (Robert Haas)
>
> (Otherwise, "all server variables using PGDLLIMPORT" could sound like only
> those "server variables [which were] using PGDLLIMPORT" were exported).

Ah, yes, I see the improvement, done.

> > > | Allow informational escape sequences to be used in postgres_fdw's application name (Hayato Kuroda, Fujii Masao)
> > >
> > > I don't think this should be a separate entry
> >
> > Uh, the entry above is about per-connection application name, while this
> > is about escapes --- seems different to me, and hard to combine.
>
> 449ab635052 postgres_fdw: Allow application_name of remote connection to be set via GUC.
> 6e0cb3dec10 postgres_fdw: Allow postgres_fdw.application_name to include escape sequences.
> 94c49d53402 postgres_fdw: Make postgres_fdw.application_name support more escape sequences.
>
> You have one entry for 449a, and one entry where you've combined 6e0c and 94c4.
>
> My point is that the 2nd two commits changed the behavior of the first commit,
> and I don't see why an end-user would want to know about the intermediate
> behavior from the middle of the development cycle when escape sequences weren't
> expanded. So I don't know why they'd be listed separately.

I see your point --- postgres_fdw.application_name supports escapes that
the normal application_name does not. I combined all three items now.
Thanks. The new entry is:

<!--
Author: Fujii Masao <fujii(at)postgresql(dot)org>
2021-09-07 [449ab6350] postgres_fdw: Allow application_name of remote connectio
Author: Fujii Masao <fujii(at)postgresql(dot)org>
2021-12-24 [6e0cb3dec] postgres_fdw: Allow postgres_fdw.application_name to inc
Author: Fujii Masao <fujii(at)postgresql(dot)org>
2022-02-18 [94c49d534] postgres_fdw: Make postgres_fdw.application_name support
-->

<listitem>
<para>
Add server variable postgres_fdw.application_name to control the
application name of postgres_fdw connections (Hayato Kuroda)
</para>

<para>
Previously the remote application_name could only be set on the
remote server or via postgres_fdw connection specification.
postgres_fdw.application_name also supports escape sequences
for customization.
</para>
</listitem>

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Indecision is a decision. Inaction is an action. Mark Batterson