Обсуждение: PG 18 relnotes and RC1

If RC1 is supposed to actually match a release candidate, we have two
problems with its release notes.  

First, the release notes are incomplete because the "new features and
enhancements" and "Acknowledgments" sections are empty.

Second, the release note item added by this commit:

    commit d1073c3b4cc
    Author: Peter Eisentraut <peter@eisentraut.org>
    Date:   Fri Aug 29 10:18:10 2025 +0200
    
        doc PG 18 relnotes: Add migration note about tsearch
    
        Document the small migration hazard introduced in commit fb1a18810f0,
        as suggested there.
    
        Reviewed-by: Daniel Verite <daniel@manitou-mail.org>
        Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
        Discussion: https://www.postgresql.org/message-id/flat/653f3b84-fc87-45a7-9a0c-bfb4fcab3e7d%40eisentraut.org

added this text to the release notes:

    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
-->    2024-12-17 [fb1a18810f0] Remove ts_locale.c's lowerstr()
    -->
    
        <listitem>
        <para>
        The locale implementation underlying full-text search was improved.  It
        now observes the locale provider configured for the database for case
        conversions.  It was previously hardcoded to use libc.  In database
        clusters that use a locale provider other than libc (that is, ICU or
        builtin) and where the locale configured through that locale provider
        behaves differently from the LC_CTYPE setting configured for the database,
        this could cause changes in behavior of some functions related to
        full-text search as well as the pg_trgm extension.  When upgrading such
        database clusters using pg_upgrade, it is recommended to reindex all
        indexes related to full-text search and pg_trgm after the upgrade.
-->        <ulink url="&commit_baseurl;fb1a18810f0">§</ulink>
        </para>
        </listitem>

Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
and throws an error because the previous line does not end with a
parenthesis.  If I add "()" after the last line in the text block, it
works fine, but obviously this is not acceptable.  I can add spaces to
two lines and that fixes it:

    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
-->    2024-12-17 [ fb1a18810f0] Remove ts_locale.c's lowerstr()
    -->
    
        <listitem>
        <para>
        The locale implementation underlying full-text search was improved.  It
        now observes the locale provider configured for the database for case
        conversions.  It was previously hardcoded to use libc.  In database
        clusters that use a locale provider other than libc (that is, ICU or
        builtin) and where the locale configured through that locale provider
        behaves differently from the LC_CTYPE setting configured for the database,
        this could cause changes in behavior of some functions related to
        full-text search as well as the pg_trgm extension.  When upgrading such
        database clusters using pg_upgrade, it is recommended to reindex all
        indexes related to full-text search and pg_trgm after the upgrade.
-->        <ulink  url="&commit_baseurl;fb1a18810f0">§</ulink>
        </para>
        </listitem>

I can commit this once our RC1 git tree freeze is over.  Is that Tuesday?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Bruce Momjian <bruce@momjian.us> writes:
> Second, the release note item added by this commit:
>     commit d1073c3b4cc
>     Author: Peter Eisentraut <peter@eisentraut.org>
>     Date:   Fri Aug 29 10:18:10 2025 +0200

> Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
> and throws an error because the previous line does not end with a
> parenthesis.  If I add "()" after the last line in the text block, it
> works fine, but obviously this is not acceptable.

I suppose that the expectation is that every release note item
will be credited to someone.  Why does this item lack a credit?

If we're okay with items not having credits, then
add_commit_links.pl's logic for where to put the <ulink>s needs
improvement.  I don't really understand why it's looking for
parens in the first place -- why isn't the rule simply "put them
before the first </para> in the item"?

In either case, I don't agree with hacky workarounds like manually
munged ulink entries ...

> I can commit this once our RC1 git tree freeze is over.  Is that Tuesday?

The release freeze doesn't apply to the release notes ;-)

            regards, tom lane

I wrote:
> If we're okay with items not having credits, then
> add_commit_links.pl's logic for where to put the <ulink>s needs
> improvement.  I don't really understand why it's looking for
> parens in the first place -- why isn't the rule simply "put them
> before the first </para> in the item"?

I revised the script to do it that way, as attached.  The results
don't change in any of our stable branches.  In v18, it makes
this change:

diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index c3e318dab00..c49eb2655eb 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -284,7 +284,7 @@ Author: Peter Eisentraut <peter@eisentraut.org>
     database clusters using pg_upgrade, it is recommended to reindex all
     indexes related to full-text search and pg_trgm after the upgrade.
 
-    <ulink url="&commit_baseurl;fb1a18810f0">§</ulink>
+<ulink url="&commit_baseurl;fb1a18810f0">§</ulink>
     </para>
     </listitem>

because of the blank line before the </para>, which is not our usual
style and should be removed IMO.  (Alternatively, we could change
the $prev_leading_space updating logic to ignore blank lines.)

            regards, tom lane

diff --git a/src/tools/add_commit_links.pl b/src/tools/add_commit_links.pl
index 710a6492032..6dda0abcd29 100755
--- a/src/tools/add_commit_links.pl
+++ b/src/tools/add_commit_links.pl
@@ -20,12 +20,13 @@
 #
 #  * File name contains the major version number preceded by a dash
 #    and followed by a period
-#  * Commit text is generated by src/tools/git_changelog
-#  * SGML comments around commit text start in the first column
-#  * The commit item title ends with an attribution that ends with
-#    a closing parentheses
-#  * previously added URL link text is unmodified
-#  * a "<para>" follows the commit item title
+#  * Commit-details text is generated by src/tools/git_changelog
+#  * SGML comment markers around commit details start in the first column
+#  * Any previously-added URL links are unmodified
+#
+# URL links will be inserted just before the first "</para>" in each
+# release note item.  They will be aligned to match the preceding line.
+# (Therefore, don't leave a blank line before that "</para>".)
 #
 # The major version number is used to select the commit hash for minor
 # releases.  An error will be generated if valid commits are found but
@@ -39,7 +40,7 @@ sub process_file
     my $file = shift;

     my $in_comment = 0;
-    my $prev_line_ended_with_paren = 0;
+    my $in_item = 0;
     my $prev_leading_space = '';
     my $lineno = 0;

@@ -50,6 +51,8 @@ sub process_file
     # Get major version number from the file name.
     $file =~ m/-(\d+)\./;
     my $major_version = $1;
+    die "file name $file is not in the expected format\n"
+      unless defined $major_version;

     open(my $fh, '<', $file) || die "could not open file $file: $!\n";
     open(my $tfh, '>', $tmpfile) || die "could not open file $tmpfile: $!\n";
@@ -58,7 +61,15 @@ sub process_file
     {
         $lineno++;

-        $in_comment = 1 if (m/^<!--/);
+        if (m/^<!--/)
+        {
+            if ($in_item)
+            {
+                print "failed to find where to add links at line $lineno\n";
+                exit(1);
+            }
+            $in_comment = 1;
+        }

         # skip over commit links because we will add them below
         next
@@ -80,36 +91,34 @@ sub process_file
               && push(@hashes, $hash);
         }

-        if (!$in_comment && m{</para>})
+        if ($in_item && m{</para>})
         {
-            if (@hashes)
+            for my $hash (@hashes)
             {
-                if ($prev_line_ended_with_paren)
-                {
-                    for my $hash (@hashes)
-                    {
-                        print $tfh
-                          "$prev_leading_space<ulink url=\"&commit_baseurl;$hash\">§</ulink>\n";
-                    }
-                    @hashes = ();
-                }
-                else
-                {
-                    print
-                      "hashes found but no matching text found for placement on line $lineno\n";
-                    exit(1);
-                }
+                print $tfh
+                  "$prev_leading_space<ulink url=\"&commit_baseurl;$hash\">§</ulink>\n";
             }
+            @hashes = ();
+            $in_item = 0;
         }

         print $tfh $_;

-        $prev_line_ended_with_paren = m/\)\s*$/;
-
+        chomp;    # don't allow newline in $prev_leading_space
         m/^(\s*)/;
         $prev_leading_space = $1;

-        $in_comment = 0 if (m/^-->/);
+        if (m/^-->/)
+        {
+            $in_comment = 0;
+            $in_item = 1 if @hashes;
+        }
+    }
+
+    if ($in_item)
+    {
+        print "failed to find where to add links at line $lineno\n";
+        exit(1);
     }

     close($fh);

On Sat, Aug 30, 2025 at 12:38:06PM -0400, Bruce Momjian wrote:
> First, the release notes are incomplete because the "new features and
> enhancements" and "Acknowledgments" sections are empty.

Corey Huinker claims to be working on the list of acknowledgments [0], but
I don't see any patches proposed yet.  AFAIK nobody has started on the "new
features and enhancements" section.

[0] https://postgr.es/m/CADkLM%3De%3DRp47yJDteZKMVGpwvNrfcE6GvnN%3D5chZuzM8jbcVNw%40mail.gmail.com

-- 
nathan

> On 30 Aug 2025, at 20:51, Nathan Bossart <nathandbossart@gmail.com> wrote:
> On Sat, Aug 30, 2025 at 12:38:06PM -0400, Bruce Momjian wrote:

>> First, the release notes are incomplete because the "new features and
>> enhancements" and "Acknowledgments" sections are empty.
> 
> Corey Huinker claims to be working on the list of acknowledgments [0], but
> I don't see any patches proposed yet.

FWIW I have a list of names of v18 contributors put together for an upcoming
talk which I intended to cross-reference against what got proposed here.  If
the list is procured in time I can make a patch out of mine.

--
Daniel Gustafsson

On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:
> AFAIK nobody has started on the "new features and enhancements" section.

Quick first attempt:

* btree skip scan
* async i/o
* oauth
* virtual generated columns
* OLD/NEW support in RETURNING
* pg_upgrade improvements (stats, --jobs, --swap)
* EXPLAIN enhancements
* uuidv7
* WITHOUT OVERLAPS/PERIOD

Thoughts?

-- 
nathan

On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:
> On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:
>> AFAIK nobody has started on the "new features and enhancements" section.
> 
> Quick first attempt:
> 
> * btree skip scan
> * async i/o
> * oauth
> * virtual generated columns
> * OLD/NEW support in RETURNING
> * pg_upgrade improvements (stats, --jobs, --swap)
> * EXPLAIN enhancements
> * uuidv7
> * WITHOUT OVERLAPS/PERIOD

The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
seems to match mine pretty closely.

[0] https://www.postgresql.org/about/news/postgresql-18-beta-1-released-3070/

-- 
nathan

On Sat, Aug 30, 2025 at 12:52:45PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Second, the release note item added by this commit:
> >     commit d1073c3b4cc
> >     Author: Peter Eisentraut <peter@eisentraut.org>
> >     Date:   Fri Aug 29 10:18:10 2025 +0200
> 
> > Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
> > and throws an error because the previous line does not end with a
> > parenthesis.  If I add "()" after the last line in the text block, it
> > works fine, but obviously this is not acceptable.
> 
> I suppose that the expectation is that every release note item
> will be credited to someone.  Why does this item lack a credit?

I don't know.

> If we're okay with items not having credits, then
> add_commit_links.pl's logic for where to put the <ulink>s needs
> improvement.  I don't really understand why it's looking for
> parens in the first place -- why isn't the rule simply "put them
> before the first </para> in the item"?

I wrote the code to insert the <ulink> when we are not in a comment,
when the line is a </para>, _and_ the previous line ends with a
parenthesis.  Maybe that was overkill, but I wanted to be as restrictive
as possible.

Actually, in this case, it caught an obvious missing attribution, so it
actually helped, so let's not change it.  I will add an attribution to
Peter Eisentraut now with the attached patch.  I also rewrote the item
to better match the surrounding text.

> In either case, I don't agree with hacky workarounds like manually
> munged ulink entries ...
> 
> > I can commit this once our RC1 git tree freeze is over.  Is that Tuesday?
> 
> The release freeze doesn't apply to the release notes ;-)

Done.  ;-)

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On Sat, Aug 30, 2025 at 02:17:15PM -0400, Tom Lane wrote:
> I wrote:
> > If we're okay with items not having credits, then
> > add_commit_links.pl's logic for where to put the <ulink>s needs
> > improvement.  I don't really understand why it's looking for
> > parens in the first place -- why isn't the rule simply "put them
> > before the first </para> in the item"?
> 
> I revised the script to do it that way, as attached.  The results
> don't change in any of our stable branches.  In v18, it makes
> this change:
> 
> diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
> index c3e318dab00..c49eb2655eb 100644
> --- a/doc/src/sgml/release-18.sgml
> +++ b/doc/src/sgml/release-18.sgml
> @@ -284,7 +284,7 @@ Author: Peter Eisentraut <peter@eisentraut.org>
>      database clusters using pg_upgrade, it is recommended to reindex all
>      indexes related to full-text search and pg_trgm after the upgrade.
>  
> -    <ulink url="&commit_baseurl;fb1a18810f0">§</ulink>
> +<ulink url="&commit_baseurl;fb1a18810f0">§</ulink>
>      </para>
>      </listitem>
> 
> because of the blank line before the </para>, which is not our usual
> style and should be removed IMO.  (Alternatively, we could change
> the $prev_leading_space updating logic to ignore blank lines.)

I ran our existing script against all the release notes back to PG 13
and saw no change if we removed the parenthesis check.  However, the
check also caught the missing attribution so I am inclined now to change
the script, unless you can explain why we would want to skip the check.

Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
> On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:
> > On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:
> >> AFAIK nobody has started on the "new features and enhancements" section.
> > 
> > Quick first attempt:
> > 
> > * btree skip scan
> > * async i/o
> > * oauth
> > * virtual generated columns
> > * OLD/NEW support in RETURNING
> > * pg_upgrade improvements (stats, --jobs, --swap)
> > * EXPLAIN enhancements
> > * uuidv7
> > * WITHOUT OVERLAPS/PERIOD
> 
> The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
> seems to match mine pretty closely.

Yes, the list usually comes from the press release.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

Bruce Momjian <bruce@momjian.us> writes:
> Actually, in this case, it caught an obvious missing attribution, so it
> actually helped, so let's not change it.

Fair enough.  I'd still like to put in the bit about

     my $major_version = $1;
+    die "file name $file is not in the expected format\n"
+      unless defined $major_version;

because the existing code does not behave nicely at all if you
point it at an incorrect file name.

> I will add an attribution to
> Peter Eisentraut now with the attached patch.  I also rewrote the item
> to better match the surrounding text.

Hmm, this text has *two* attributions to Peter, and
add_commit_links.pl disagrees with you on where to put the URL.

            regards, tom lane

On Sat, Aug 30, 2025 at 06:04:16PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Actually, in this case, it caught an obvious missing attribution, so it
> > actually helped, so let's not change it.
> 
> Fair enough.  I'd still like to put in the bit about
> 
>      my $major_version = $1;
> +    die "file name $file is not in the expected format\n"
> +      unless defined $major_version;
> 
> because the existing code does not behave nicely at all if you
> point it at an incorrect file name.

Good fix, done.

> > I will add an attribution to
> > Peter Eisentraut now with the attached patch.  I also rewrote the item
> > to better match the surrounding text.
> 
> Hmm, this text has *two* attributions to Peter, and
> add_commit_links.pl disagrees with you on where to put the URL.

Oops, fixed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On Sat, Aug 30, 2025 at 05:56:12PM -0400, Bruce Momjian wrote:
> On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
>> The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
>> seems to match mine pretty closely.
> 
> Yes, the list usually comes from the press release.

Here is a first attempt at converting the press release into bullet points.

-- 
nathan

> On Aug 30, 2025, at 5:56 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
>>> On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:
>>> On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:
>>>> AFAIK nobody has started on the "new features and enhancements" section.
>>>
>>> Quick first attempt:
>>>
>>> * btree skip scan
>>> * async i/o
>>> * oauth
>>> * virtual generated columns
>>> * OLD/NEW support in RETURNING
>>> * pg_upgrade improvements (stats, --jobs, --swap)
>>> * EXPLAIN enhancements
>>> * uuidv7
>>> * WITHOUT OVERLAPS/PERIOD
>>
>> The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
>> seems to match mine pretty closely.
>
> Yes, the list usually comes from the press release.

I was planning to propose this after I post the GA announcement draft, which I’m finishing up this weekend.

Thanks,

Jonathan

On 30.08.25 18:52, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Second, the release note item added by this commit:
>>     commit d1073c3b4cc
>>     Author: Peter Eisentraut <peter@eisentraut.org>
>>     Date:   Fri Aug 29 10:18:10 2025 +0200
> 
>> Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
>> and throws an error because the previous line does not end with a
>> parenthesis.  If I add "()" after the last line in the text block, it
>> works fine, but obviously this is not acceptable.
> 
> I suppose that the expectation is that every release note item
> will be credited to someone.  Why does this item lack a credit?

Maybe I'm understanding this differently, but the "Migration" section 
ought to be advice about the migration, which is not a place to 
communicate credit.  In the case I added, the item is the result of some 
changes that are already listed and credited elsewhere in the "Changes" 
section.

Peter Eisentraut <peter@eisentraut.org> writes:
> On 30.08.25 18:52, Tom Lane wrote:
>> I suppose that the expectation is that every release note item
>> will be credited to someone.  Why does this item lack a credit?

> Maybe I'm understanding this differently, but the "Migration" section 
> ought to be advice about the migration, which is not a place to 
> communicate credit.  In the case I added, the item is the result of some 
> changes that are already listed and credited elsewhere in the "Changes" 
> section.

One answer could be to remove the commit-details comment block from
that item, thereby making the added URL go away too.  However, that
will look a bit odd when the neighboring items all have credits and
URLs.

I think our past practice has been to list any one item either in
Migration or the following sections, not in both places.  This item
seems to adhere to that too: I don't see that commit hash anywhere
else.  So I'm not clear why you're finding this duplicative?

            regards, tom lane

On Sun, Aug 31, 2025 at 01:34:26PM +0200, Peter Eisentraut wrote:
> On 30.08.25 18:52, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > Second, the release note item added by this commit:
> > >     commit d1073c3b4cc
> > >     Author: Peter Eisentraut <peter@eisentraut.org>
> > >     Date:   Fri Aug 29 10:18:10 2025 +0200
> > 
> > > Unfortunately src/tools/add_commit_links.pl can't process the <ulink>
> > > and throws an error because the previous line does not end with a
> > > parenthesis.  If I add "()" after the last line in the text block, it
> > > works fine, but obviously this is not acceptable.
> > 
> > I suppose that the expectation is that every release note item
> > will be credited to someone.  Why does this item lack a credit?
> 
> Maybe I'm understanding this differently, but the "Migration" section ought
> to be advice about the migration, which is not a place to communicate
> credit.  In the case I added, the item is the result of some changes that
> are already listed and credited elsewhere in the "Changes" section.

So, this gets back to the the actual purpose of giving credit, and we
have discussed this at length in the past.  If an item is worth
mentioning in the release notes because of its impact on users, it is
worth adding attributions, since the attributions are small, and easily
skipped.  What I have not done is to add items that do not fit that
criteria solely to give attribution, and that has upset some.

I have used the same criteria in the "Migration" section since I see no
reason to deviate from that policy in that section, and you will see
that in the PG 18 "Migration" section for other items.  Years ago, I
think before I was adding commit hashes, I used to not attribute
migration items if they were referenced later, but at this point, with
the need for commit markers anyway, we might as well just repeat the
attribution to keep it consistent.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On Sun, Aug 31, 2025 at 10:34:43AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
> > On 30.08.25 18:52, Tom Lane wrote:
> >> I suppose that the expectation is that every release note item
> >> will be credited to someone.  Why does this item lack a credit?
> 
> > Maybe I'm understanding this differently, but the "Migration" section 
> > ought to be advice about the migration, which is not a place to 
> > communicate credit.  In the case I added, the item is the result of some 
> > changes that are already listed and credited elsewhere in the "Changes" 
> > section.
> 
> One answer could be to remove the commit-details comment block from
> that item, thereby making the added URL go away too.  However, that
> will look a bit odd when the neighboring items all have credits and
> URLs.

Yes, and that would make it hard to find the commit used for the change,
which can be helpful for users.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On 31.08.25 16:34, Tom Lane wrote:
> I think our past practice has been to list any one item either in
> Migration or the following sections, not in both places.  This item
> seems to adhere to that too: I don't see that commit hash anywhere
> else.  So I'm not clear why you're finding this duplicative?

I don't have the complete picture of how the release notes are composed. 
  I just wanted to add some helpful advice relevant to the migration to 
PG18, and the Migration section seemed the right place for it.

Looking at it closer, I think this practice you are describing is 
inferior.  For one thing, it makes the "Changes" section incomplete:  It 
should be labeled, "Changes except the ones already listed above".  More 
importantly, it constrains how the advice in the Migration section can 
be structured.  It has to be a change description tied to specific 
commits and credit, whereas as someone doing the migration, I'm looking 
for differently-structured advice.

For example, looking at the item in the Migration section

* Remove column pg_backend_memory_contexts.parent (Melih Mutlu) §

   This is no longer needed since pg_backend_memory_contexts.path was
   added.

This might be ok as a summary of a description of a code change.  But as 
someone doing a migration, I don't know what to do with that.  If I'm 
using PG17 and I'm using the old column, now what?

As another example, the advice on how to handle the change to checksum 
enable by default in pg_upgrade is very terse and barely useful.

The Migration section should be written like "If you are using ... then 
you should be doing ... {before|after} upgrading."

This can be inferred from many of the items, but several of them not.

On Sun, Aug 31, 2025 at 08:51:40PM +0200, Peter Eisentraut wrote:
> On 31.08.25 16:34, Tom Lane wrote:
> > I think our past practice has been to list any one item either in
> > Migration or the following sections, not in both places.  This item
> > seems to adhere to that too: I don't see that commit hash anywhere
> > else.  So I'm not clear why you're finding this duplicative?
> 
> I don't have the complete picture of how the release notes are composed.  I
> just wanted to add some helpful advice relevant to the migration to PG18,
> and the Migration section seemed the right place for it.
> 
> Looking at it closer, I think this practice you are describing is inferior.
> For one thing, it makes the "Changes" section incomplete:  It should be
> labeled, "Changes except the ones already listed above".  More importantly,
> it constrains how the advice in the Migration section can be structured.  It
> has to be a change description tied to specific commits and credit, whereas
> as someone doing the migration, I'm looking for differently-structured
> advice.
> 
> For example, looking at the item in the Migration section
> 
> * Remove column pg_backend_memory_contexts.parent (Melih Mutlu) §
> 
>   This is no longer needed since pg_backend_memory_contexts.path was
>   added.
> 
> This might be ok as a summary of a description of a code change.  But as
> someone doing a migration, I don't know what to do with that.  If I'm using
> PG17 and I'm using the old column, now what?
> 
> As another example, the advice on how to handle the change to checksum
> enable by default in pg_upgrade is very terse and barely useful.
> 
> The Migration section should be written like "If you are using ... then you
> should be doing ... {before|after} upgrading."
> 
> This can be inferred from many of the items, but several of them not.

My initial reaction to this is to move "Migration" under "Changes", and
change the "Migration" title to "Changes Affecting Migration".

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

On 31.08.25 05:02, Nathan Bossart wrote:
> On Sat, Aug 30, 2025 at 05:56:12PM -0400, Bruce Momjian wrote:
>> On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
>>> The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
>>> seems to match mine pretty closely.
>>
>> Yes, the list usually comes from the press release.
> 
> Here is a first attempt at converting the press release into bullet points.

This seems fine.  I suggest you commit this, so we get it done.

> On Sep 17, 2025, at 2:47 PM, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 31.08.25 05:02, Nathan Bossart wrote:
>>> On Sat, Aug 30, 2025 at 05:56:12PM -0400, Bruce Momjian wrote:
>>> On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
>>>> The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
>>>> seems to match mine pretty closely.
>>>
>>> Yes, the list usually comes from the press release.
>> Here is a first attempt at converting the press release into bullet points.
>
> This seems fine.  I suggest you commit this, so we get it done.

I had messaged Bruce saying I was going to draft today, latest tomorrow. Please hold off.

Jonathan

On 9/17/25 2:51 PM, Jonathan S. Katz wrote:
> 
>> On Sep 17, 2025, at 2:47 PM, Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> On 31.08.25 05:02, Nathan Bossart wrote:
>>>> On Sat, Aug 30, 2025 at 05:56:12PM -0400, Bruce Momjian wrote:
>>>> On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
>>>>> The 18beta1 announcement [0] has a good list, too.  *facepalm*  That one
>>>>> seems to match mine pretty closely.
>>>>
>>>> Yes, the list usually comes from the press release.
>>> Here is a first attempt at converting the press release into bullet points.
>>
>> This seems fine.  I suggest you commit this, so we get it done.
> 
> I had messaged Bruce saying I was going to draft today, latest tomorrow. Please hold off.

Please see attached draft for the major features of PostgreSQL 18.

Thanks,

Jonathan

Op 9/18/25 om 18:08 schreef Jonathan S. Katz:
> 
> Please see attached draft for the major features of PostgreSQL 18.
[...]
 > [v2-0001-add-major-features-to-v18-release-notes.patch]

One typo:

that can improves throughput  should be
that can improve throughput

Erik

On Thu, Sep 18, 2025 at 12:09 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Please see attached draft for the major features of PostgreSQL 18.

I like Nathan's version better. I suggest we go with that one.

--
Robert Haas
EDB: http://www.enterprisedb.com

> On Sep 18, 2025, at 12:20 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Sep 18, 2025 at 12:09 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> Please see attached draft for the major features of PostgreSQL 18.
>
> I like Nathan's version better. I suggest we go with that one.

Why? This seems arbitrary without more details.

I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a presentation
onit that was delivered last night, also culminating in the press release. I put a lot of effort into researching what
tohighlight up top, which is augmented in the release details itself. Additionally I started from what Nathan had and
tweakeda few items. 

If there something you specifically disagree with I’d like to better understand.

Jonathan

> --
> Robert Haas
> EDB: http://www.enterprisedb.com

On Thu, Sep 18, 2025 at 12:59 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> > I like Nathan's version better. I suggest we go with that one.
>
> Why? This seems arbitrary without more details.
>
> I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a presentation
onit that was delivered last night, also culminating in the press release. I put a lot of effort into researching what
tohighlight up top, which is augmented in the release details itself. Additionally I started from what Nathan had and
tweakeda few items. 

That seems completely backwards to me. We should go with the version
that was submitted weeks ago and upon which people have had the
opportunity to comment unless you can justify each change that you now
want to make at the last minute. Why for example should we drop
mentioning the ability to return OLD.* and NEW.* in favor of mentioned
UUIDv7? I'd argue that the former is more important than the latter,
and I don't see how you can argue otherwise except by appealing to the
research you've done over the last several weeks. But none of us have
access to that or got a vote in it. These things ought to be decided
by consensus. If you want your research to feed into the building of
that consensus, you need to do it and present it earlier. For example,
if you want to present survey results, I think that's a great way to
help decide these kinds of things, but then other people should have
the right to present their own survey results and so on in that
conversation too.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Thu, Sep 18, 2025 at 01:38:44PM -0400, Robert Haas wrote:
> That seems completely backwards to me. We should go with the version
> that was submitted weeks ago and upon which people have had the
> opportunity to comment unless you can justify each change that you now
> want to make at the last minute. Why for example should we drop
> mentioning the ability to return OLD.* and NEW.* in favor of mentioned
> UUIDv7? I'd argue that the former is more important than the latter,
> and I don't see how you can argue otherwise except by appealing to the
> research you've done over the last several weeks. But none of us have
> access to that or got a vote in it. These things ought to be decided
> by consensus. If you want your research to feed into the building of
> that consensus, you need to do it and present it earlier. For example,
> if you want to present survey results, I think that's a great way to
> help decide these kinds of things, but then other people should have
> the right to present their own survey results and so on in that
> conversation too.

Quick analysis of the differences:

    Common:
    * AIO
    * skip scan
    * pg_upgrade
    * UUIDv7
    * virtual generated columns
    * OAuth

    Only v1 (my patch):
    * OLD/NEW for RETURNING
    * temporal constraints
    * EXPLAIN enhancements

    Only v2 (Jonathan's):
    * conflict logging

While the EXPLAIN enhancements and conflict logging items seem like super
useful features, I can see how there might be disagreement over whether
they belong in the major features list.  I'm a little more surprised about
the omission of OLD/NEW and temporal contraints in v2, though.

That being said, I'm tempted to suggest we UNION the two lists, bikeshed
over the exact wording for a few hours, and then call it day...

-- 
nathan

On 9/18/25 1:38 PM, Robert Haas wrote:
> On Thu, Sep 18, 2025 at 12:59 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>> I like Nathan's version better. I suggest we go with that one.
>>
>> Why? This seems arbitrary without more details.
>>
>> I’ve spent the past several weeks staring at the release notes, talking to users, and putting together a
presentationon it that was delivered last night, also culminating in the press release. I put a lot of effort into
researchingwhat to highlight up top, which is augmented in the release details itself. Additionally I started from what
Nathanhad and tweaked a few items.
 
> 
> That seems completely backwards to me.

Glad to hear I've been doing my job backwards for years ;) That said, I 
am always willing to learn how to improve the process.

> We should go with the version
> that was submitted weeks ago and upon which people have had the
> opportunity to comment unless you can justify each change that you now
> want to make at the last minute.

Happy to justify all of this. First, with a few more weeks, we have more 
data points on how things are going to be used, so it's OK to make it at 
this opint.
> Why for example should we  drop
> mentioning the ability to return OLD.* and NEW.* in favor of mentioned
> UUIDv7?

UUIDv7 was in the original one, and it's been carried forward. The 
change was I explicitly brought in the function name and the link to it.

> I'd argue that the former is more important than the latter,
> and I don't see how you can argue otherwise except by appealing to the
> research you've done over the last several weeks.

UUIDs are more used way more than RETURNING statements. For example, 
last night at the PG18 meetup, everyone's hand went up for using UUIDs, 
and no one's hand went up for RETURNING. I did demo that feature last 
night and it was pretty cool, and many ORMs use RETURNING on DML 
statements to return the info and it's a neat feature. I'm not opposed 
to including it in there, but I didn't include it in this draft because 
it comes from something that doesn't impact as many users.

That said, if people feel strongly about it, I'm OK to add it back.

> But none of us have
> access to that or got a vote in it. These things ought to be decided
> by consensus. If you want your research to feed into the building of
> that consensus, you need to do it and present it earlier. 

I posted a patch now; there's still a few days before this is finalized, 
and we can iterate on it. The press release was also posted a few weeks 
back with time for people to comment on it, too.

This is a task I've helped on every year for nearly a decade and there 
have been limited complaints, other than a healthy discussion on what 
features should be in the list. For personal reasons I didn't get to 
this specific part as early as usual, and given my history of the work 
I've done on the release, I would have expected a bit more empathy 
towards pulling this together. And of course, I'm always open to 
well-stated opinions on what to do.

> For example,
> if you want to present survey results, I think that's a great way to
> help decide these kinds of things, but then other people should have
> the right to present their own survey results and so on in that
> conversation too.

That's great - your original comment didn't do that though, and I could 
have better stated why I put together the list as is.

I will go look at Nathan's original patch one more time at the delta and 
post a revision shortly.

Thanks,

Jonathan

On 9/18/25 2:19 PM, Nathan Bossart wrote:
> On Thu, Sep 18, 2025 at 01:38:44PM -0400, Robert Haas wrote:
>> That seems completely backwards to me. We should go with the version
>> that was submitted weeks ago and upon which people have had the
>> opportunity to comment unless you can justify each change that you now
>> want to make at the last minute. Why for example should we drop
>> mentioning the ability to return OLD.* and NEW.* in favor of mentioned
>> UUIDv7? I'd argue that the former is more important than the latter,
>> and I don't see how you can argue otherwise except by appealing to the
>> research you've done over the last several weeks. But none of us have
>> access to that or got a vote in it. These things ought to be decided
>> by consensus. If you want your research to feed into the building of
>> that consensus, you need to do it and present it earlier. For example,
>> if you want to present survey results, I think that's a great way to
>> help decide these kinds of things, but then other people should have
>> the right to present their own survey results and so on in that
>> conversation too.
> 
> Quick analysis of the differences:
> 
>      Common:
>      * AIO
>      * skip scan
>      * pg_upgrade
>      * UUIDv7
>      * virtual generated columns
>      * OAuth
> 
>      Only v1 (my patch):
>      * OLD/NEW for RETURNING
>      * temporal constraints
>      * EXPLAIN enhancements
> 
>      Only v2 (Jonathan's):
>      * conflict logging
> 
> While the EXPLAIN enhancements and conflict logging items seem like super
> useful features, I can see how there might be disagreement over whether
> they belong in the major features list.  I'm a little more surprised about
> the omission of OLD/NEW and temporal contraints in v2, though.
> 
> That being said, I'm tempted to suggest we UNION the two lists, bikeshed
> over the exact wording for a few hours, and then call it day...

Let's hack on this together for a few and bring a proposal to the list.

Jonathan

On 9/18/25 2:33 PM, Jonathan S. Katz wrote:
> On 9/18/25 2:19 PM, Nathan Bossart wrote:

>> Quick analysis of the differences:
>>
>>      Common:
>>      * AIO
>>      * skip scan
>>      * pg_upgrade
>>      * UUIDv7
>>      * virtual generated columns
>>      * OAuth
>>
>>      Only v1 (my patch):
>>      * OLD/NEW for RETURNING
>>      * temporal constraints
>>      * EXPLAIN enhancements
>>
>>      Only v2 (Jonathan's):
>>      * conflict logging
>>
>> While the EXPLAIN enhancements and conflict logging items seem like super
>> useful features, I can see how there might be disagreement over whether
>> they belong in the major features list.  I'm a little more surprised 
>> about
>> the omission of OLD/NEW and temporal contraints in v2, though.
>>
>> That being said, I'm tempted to suggest we UNION the two lists, bikeshed
>> over the exact wording for a few hours, and then call it day...
> 
> Let's hack on this together for a few and bring a proposal to the list.

Nathan & I hopped on a call to "pair program" on this. Given the point 
that his patch had been available on the list for awhile with limited 
public comments to date, we did the following:

* Kept everything except EXPLAIN enhancements and conflict logging. For 
the former, a lot of this wasn't in the default EXPLAIN path. For the 
latter, this was to respect the time period of the discussion.

* Did some minor wordsmithing and linking to help with overall 
accessibility, including Erik's typo catch.

Many thanks to Nathan for pulling this together. Please see v3. Feedback 
welcome.

Thanks,

Jonathan

On Thu, Sep 18, 2025 at 2:19 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Glad to hear I've been doing my job backwards for years ;) That said, I
> am always willing to learn how to improve the process.

I don't really care for the flip tone here. I do think there's a
problem here, and I do think it's longstanding. I think it predates
your involvement, but whether it does or not I'd like to fix it.
That's not an accusation that you're doing anything backwards or not,
it's just the facts as I see them.

> > Why for example should we  drop
> > mentioning the ability to return OLD.* and NEW.* in favor of mentioned
> > UUIDv7?
>
> UUIDv7 was in the original one, and it's been carried forward. The
> change was I explicitly brought in the function name and the link to it.

You're right. That's my mistake.

> I posted a patch now; there's still a few days before this is finalized,
> and we can iterate on it. The press release was also posted a few weeks
> back with time for people to comment on it, too.
>
> This is a task I've helped on every year for nearly a decade and there
> have been limited complaints, other than a healthy discussion on what
> features should be in the list. For personal reasons I didn't get to
> this specific part as early as usual, and given my history of the work
> I've done on the release, I would have expected a bit more empathy
> towards pulling this together. And of course, I'm always open to
> well-stated opinions on what to do.

I am very grateful for all of the work that everyone does to make
releases happen, and I very much appreciate being able to work on a
piece of software that is as great as PostgreSQL without always having
to sweat all the details of getting it out the door. Nevertheless, I
think the problem of the major features list being chronically late is
a longstanding one, and I think we should try to find a way to fix it.

There was one year that Bruce wasn't able to write the release notes
when the community wanted them due to other time commitments and he
disclosed that. We then discussed whether to go with having him do
them at a later time or have someone else do them, and chose the
latter option. I ended up doing them that year. I'm grateful that I
haven't had to do that again because it was a lot of work, but I'm
ALSO grateful that Bruce was upfront about the problem and willing to
cede the responsibility to someone who had more time available during
the critical window. If whatever prevented Bruce from doing the
release notes at the usual time was something deserving of sympathy,
then my sympathy was his for the asking, as is yours. But that is
really a personal conversation that in my view shouldn't have much to
do with how the project assigns tasks. If for example a committer has
a personal issue come up right before feature freeze, we may on a
personal level have a lot of sympathy for them if the result is that
their big feature misses the release, but we have yet to grant a
feature freeze exemption to someone on the basis of something like
that happening, and I don't think we should.

As I see it, while our feature freeze isn't perfect -- mostly because
too many things get slipped in at the last minute that aren't really
in great shape -- it's a lot better than the old process where nobody
really knew what the deadline was. Similarly here, we should just
agree on some deadline for when the PR and major feature tasks should
get completed; and if you or whoever don't think you're going to be
able to make those timelines, then we can either decide on someone
else to do it or we can decide to move the deadline. Either way, if we
do that, we're operating by consensus and a shared set of
expectations.

--
Robert Haas
EDB: http://www.enterprisedb.com

On Thu, Sep 18, 2025 at 03:25:08PM -0400, Robert Haas wrote:
> As I see it, while our feature freeze isn't perfect -- mostly because
> too many things get slipped in at the last minute that aren't really
> in great shape -- it's a lot better than the old process where nobody
> really knew what the deadline was. Similarly here, we should just
> agree on some deadline for when the PR and major feature tasks should
> get completed; and if you or whoever don't think you're going to be
> able to make those timelines, then we can either decide on someone
> else to do it or we can decide to move the deadline. Either way, if we
> do that, we're operating by consensus and a shared set of
> expectations.

I think we ought to set a deadline of, say, beta2 or beta3 and have the RMT
responsible for making sure it happens.  Either of those releases would
still give us at least a month or so to address feedback before GA, but
they aren't so early as to require lots of rework due to last-minute
changes.

-- 
nathan

On Thu, Sep 18, 2025 at 3:32 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> I think we ought to set a deadline of, say, beta2 or beta3 and have the RMT
> responsible for making sure it happens.  Either of those releases would
> still give us at least a month or so to address feedback before GA, but
> they aren't so early as to require lots of rework due to last-minute
> changes.

That would be fine with me. I'd prefer beta2 -- I think it's really
awkward to try to talk up a forthcoming release when the list of major
features is blank for so long, and I think it's nice to give more
people time to bikeshed the list, too, if anyone is inclined to do
that.

--
Robert Haas
EDB: http://www.enterprisedb.com

On 9/18/25 3:25 PM, Robert Haas wrote:
> On Thu, Sep 18, 2025 at 2:19 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> Glad to hear I've been doing my job backwards for years ;) That said, I
>> am always willing to learn how to improve the process.
> 
> I don't really care for the flip tone here.

I didn't really care for your tone with me in the first few emails, 
either. I'm glad we agree it's unproductive.

I'm happy to discuss the rest of your note later, as there are valid 
points in it. First, let's get this portion of the release done, and 
I'll use the time and energy to finish up the rest of the release items 
on my plate ahead of the GA.

Jonathan

On 9/18/25 3:32 PM, Nathan Bossart wrote:
> On Thu, Sep 18, 2025 at 03:25:08PM -0400, Robert Haas wrote:
>> As I see it, while our feature freeze isn't perfect -- mostly because
>> too many things get slipped in at the last minute that aren't really
>> in great shape -- it's a lot better than the old process where nobody
>> really knew what the deadline was. Similarly here, we should just
>> agree on some deadline for when the PR and major feature tasks should
>> get completed; and if you or whoever don't think you're going to be
>> able to make those timelines, then we can either decide on someone
>> else to do it or we can decide to move the deadline. Either way, if we
>> do that, we're operating by consensus and a shared set of
>> expectations.
> 
> I think we ought to set a deadline of, say, beta2 or beta3 and have the RMT
> responsible for making sure it happens.  Either of those releases would
> still give us at least a month or so to address feedback before GA, but
> they aren't so early as to require lots of rework due to last-minute
> changes.

I'm OK in theory with pulling in the deadline for the PR and major 
features - there is a bunch of work that has to happen after the PR that 
is fairly time consuming (translations, website work, feature matrix, 
etc.). But let's also look at this holistically, because we had a big 
crunch this year with Beta 1 + .dev + out-of-cycle releases that make 
this a big crunch.

So, let's have the discussion, but after this GA but before PG19 beta1 :)

Jonathan

On Thu, Sep 18, 2025 at 03:05:52PM -0400, Jonathan S. Katz wrote:
> Many thanks to Nathan for pulling this together. Please see v3. Feedback
> welcome.

I'm hoping to commit this around 20:00 UTC today, and I will be happy to
address any feedback that folks have in the meantime.

-- 
nathan

On Fri, Sep 19, 2025 at 09:25:52AM -0500, Nathan Bossart wrote:
> I'm hoping to commit this around 20:00 UTC today, and I will be happy to
> address any feedback that folks have in the meantime.

Here's a v4.  The content is the same except for a typo fix, some
formatting adjustments that don't change anything in the generated page,
and a real commit message.  I'm okay with the content, but I figured I'd
note some thoughts:

+      An asynchronous I/O subsystem (AIO) that can improve performance of
+      sequential scans, bitmap heap scans, vacuums, and other operations.

I wondered whether we should put "(AIO)" before "subsystem", but I think
putting it next to "I/O" makes the line too busy.  Also, are there "other
operations", or is the rest of the list complete?

+      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
+      now maintains optimizer statistics through upgrade.

I think "retain" might be a better verb than "maintain", but the meaning
seems clear either way.  Also, while we could probably omit "through
upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
a bit.

+      Support for "skip scan" lookups that allow
+      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
+      be used in more cases.

Passive voice.  Perhaps this should be "that allow using ... in more
cases."

+      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
+      that compute their values during read operations.  This is now the
+      default for generated columns.

I liked the phrase "just-in-time" for this because it expresses how it
works.  Perhaps we should squeeze that in before "during read operations".

-- 
nathan

On 9/19/25 12:50 PM, Nathan Bossart wrote:
> On Fri, Sep 19, 2025 at 09:25:52AM -0500, Nathan Bossart wrote:
>> I'm hoping to commit this around 20:00 UTC today, and I will be happy to
>> address any feedback that folks have in the meantime.
> 
> Here's a v4.  The content is the same except for a typo fix, some
> formatting adjustments that don't change anything in the generated page,
> and a real commit message.  I'm okay with the content, but I figured I'd
> note some thoughts:
> 
> +      An asynchronous I/O subsystem (AIO) that can improve performance of
> +      sequential scans, bitmap heap scans, vacuums, and other operations.
> 
> I wondered whether we should put "(AIO)" before "subsystem", but I think
> putting it next to "I/O" makes the line too busy.  Also, are there "other
> operations", or is the rest of the list complete?

Will throw out the "we can just remove it" option like further down in 
the release notes, but figure we've put the AIO terminology out there 
enough it may be good to assign the too. Anyway, if we keep it, I'd 
suggest "asynchronous I/O (AIO)" given it's modifying that.

For "other operations", the release notes have "etc." in them. But if we 
want to hedge, we can do:

...that can improve performance of operations, including sequential 
scans, bitmap heap scans, and vacuums."

> +      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
> +      now maintains optimizer statistics through upgrade.
> 
> I think "retain" might be a better verb than "maintain", but the meaning
> seems clear either way.  Also, while we could probably omit "through
> upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
> a bit.

OK with "retains", and OK w/dropping "through upgrade".

> +      Support for "skip scan" lookups that allow
> +      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
> +      be used in more cases.
> 
> Passive voice.  Perhaps this should be "that allow using ... in more
> cases."

Agreed switching to active voice.

> +      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
> +      that compute their values during read operations.  This is now the
> +      default for generated columns.
> 
> I liked the phrase "just-in-time" for this because it expresses how it
> works.  Perhaps we should squeeze that in before "during read operations".

I think "during" and "just-in-time" are equivalent here. Also wanted to 
be sensitive to the fact we already have a feature called 
"just-in-time"/"JIT" for compilation, and didn't want people to confuse 
the two.

Jonathan

On Fri, Sep 19, 2025 at 01:04:26PM -0400, Jonathan S. Katz wrote:
> On 9/19/25 12:50 PM, Nathan Bossart wrote:
>> +      An asynchronous I/O subsystem (AIO) that can improve performance of
>> +      sequential scans, bitmap heap scans, vacuums, and other operations.
>> 
>> I wondered whether we should put "(AIO)" before "subsystem", but I think
>> putting it next to "I/O" makes the line too busy.  Also, are there "other
>> operations", or is the rest of the list complete?
> 
> Will throw out the "we can just remove it" option like further down in the
> release notes, but figure we've put the AIO terminology out there enough it
> may be good to assign the too. Anyway, if we keep it, I'd suggest
> "asynchronous I/O (AIO)" given it's modifying that.

Done.

> For "other operations", the release notes have "etc." in them. But if we
> want to hedge, we can do:
> 
> ...that can improve performance of operations, including sequential scans,
> bitmap heap scans, and vacuums."

I left this alone.

>> +      <link linkend="pgupgrade"><application>pg_upgrade</application></link>
>> +      now maintains optimizer statistics through upgrade.
>> 
>> I think "retain" might be a better verb than "maintain", but the meaning
>> seems clear either way.  Also, while we could probably omit "through
>> upgrade", the small amount of redundancy does (IMHO) reinforce the meaning
>> a bit.
> 
> OK with "retains", and OK w/dropping "through upgrade".

Done.

>> +      Support for "skip scan" lookups that allow
>> +      <link linkend="indexes-multicolumn">multicolumn B-tree indexes</link> to
>> +      be used in more cases.
>> 
>> Passive voice.  Perhaps this should be "that allow using ... in more
>> cases."
> 
> Agreed switching to active voice.

Done.

>> +      <link linkend="sql-createtable-parms-generated-stored">generated columns</link>
>> +      that compute their values during read operations.  This is now the
>> +      default for generated columns.
>> 
>> I liked the phrase "just-in-time" for this because it expresses how it
>> works.  Perhaps we should squeeze that in before "during read operations".
> 
> I think "during" and "just-in-time" are equivalent here. Also wanted to be
> sensitive to the fact we already have a feature called "just-in-time"/"JIT"
> for compilation, and didn't want people to confuse the two.

I left this alone, too.

-- 
nathan

Committed.

-- 
nathan

On 9/19/25 4:09 PM, Nathan Bossart wrote:
> Committed.

Thanks!

Jonathan