Re: First draft of the PG 15 release notes

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.GT23027@telsasoft.com.
> 
> 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.

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

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

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

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

-- 
Justin