Обсуждение: PostgreSQL 18 GA press release draft

Hi,

Attached is a draft of the PostgreSQL 18 GA press release. A few 
comments before the ask for reviewing:

* I still need to write up the theme and the quote, which I'll provide 
tomorrow after hearing the first round of feedback
* The release is a bit long - this is due in part to what I think is a 
lot of really good features in PostgreSQL 18. "Something for everyone"

Please review for the press release for the following:

* Correctness and accuracy of what's described - we want to be 
technically correct, but we also need to explain why something matters 
to our users.
* Notable omissions (apologies if I missed something, but also note not 
everything going to make the cut).
* Features to exclude.
* How easy phrases are to translate / confusing phrases
* Typos.

Like previous years, I won't really look at stylistic remarks, unless it 
falls into the "making it simpler to translate / confusing phrase" bucket.

After 2025-09-14 0:00 UTC I won't be able to accept more feedback, as 
we'll need to begin the translation process. Anyone who provides 
accepted feedback will also get a mention in the press release "thank 
you" page[1], which stays up for about a year ;)

Thanks for your help!

Jonathan

[1] https://www.postgresql.org/about/press/

FWIW, here are a couple of AI-detected issues.

This typo:
"with contains installers" should be "which contains installers"

This potential mismatch:
"Built on over 35 years of engineering" is inconsistent with the
earlier "nearly 30 years" statement?

======
Kind Regards,
Peter Smith.
Fujitsu Australia.

On Wed, Sep 10, 2025 at 11:13 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> Hi,
>
> Please review for the press release for the following:
>
> * Correctness and accuracy of what's described - we want to be
> technically correct, but we also need to explain why something matters
> to our users.

PostgreSQL 18 adds [temporal
constraints](https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-CONSTRAINTS)
-- constraints over ranges -- for both `PRIMARY KEY` and `UNIQUE`
constraints using the `WITHOUT OVERLAPS` clause, and on `FOREIGN KEY`
constraints using the `PERIOD` clause.

this link (https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-CONSTRAINTS)
seems not that appropriate, since it does not explain WITHOUT OVERLAPS,
link (https://www.postgresql.org/docs/devel/sql-createtable.html#SQL-CREATETABLE-PARMS-UNIQUE)
would be more appropriate?

On Wed, Sep 10, 2025 at 5:14 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> Hi,
>
> Attached is a draft of the PostgreSQL 18 GA press release. A few
> comments before the ask for reviewing:
>

Hi Jonathan,

> Finally, PostgreSQL 18 introduces support for [NUMA
awareness](https://www.postgresql.org/docs/18/install-make.html#CONFIGURE-OPTION-WITH-LIBNUMA)that adds basic [NUMA
observability](https://www.postgresql.org/docs/18/view-pg-shmem-allocations-numa.html)to PostgreSQL. 

For some reason I find this sentence not accurate: NUMA awareness
somehow indicates that we get performance benefits out of this, but we
do not (yet*)  - we simply provide some insight into NUMA memory
layout so far and link against libnuma.  So maybe we should remove
"introduces support for [NUMA
awareness](https://www.postgresql.org/docs/18/install-make.html#CONFIGURE-OPTION-WITH-LIBNUMA)
that"
and just leave it as
"Finally, PostgreSQL 18 adds basic [NUMA observability]" ?

Rationale: for every other software that I saw NUMA awareness
reference was always linked to gaining performance , but just linking
against libnuma is not giving us this.

* = with on going work for 19 (future Tomas's we'll get there I hope)

-J.

On Wed, Sep 10, 2025 at 10:13 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:

> PostgreSQL 18 also supports using x86 AVX-512 instructions for CRC32 calculations, which are used in page checksums
andare also available in the new
[`crc32`](https://www.postgresql.org/docs/18/functions-binarystring.html#FUNCTIONS-BINARYSTRING-OTHER)function. 

Hi Jon,

The checksum stored in the page header is not actually a CRC but
something else entirely. WAL records are a convenient example of
something that uses CRC.

Also, CRC32 is not hardware accelerated, only CRC32C is. We have two
SQL-callable functions.  To avoid confusion maybe they can be omitted
from this longer-than-usual announcement -- they seem like a niche
feature anyway.

--
John Naylor
Amazon Web Services

On Tue, Sep 9, 2025 at 11:13 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Attached is a draft of the PostgreSQL 18 GA press release.

I have some feedback on this sentence:

"It can also automatically optimize queries using `OR` or `IN (VALUES
...)` in `WHERE` clauses for faster execution".

This is factually correct, but I think that it gives too much
importance to the `IN (VALUES ...)` transformation added by commit
c0962a11. IMV we shouldn't mention anything about transformations that
affect queries that use IN(), since it only applies to `IN (VALUES
...)` -- which is a rather limited special case. Especially because
this IN(VALUES()) case is limited to transforming queries that only
have true constants in the VALUES() clause -- it cannot work with
parameters at all.

I say this in part because I've noticed that existing press reports
about this functionality (which were based on the beta1 announcement)
say that it affects IN() queries in general, which isn't true. Again,
I know that you haven't made that same mistake here -- but a lot of
people will read `IN (VALUES ...)` as "any and all IN() lists".
They'll tend to interpret "VALUES" as "some values that appear in an
IN()", and not "a VALUES() clause that appears in an IN()".

The work from commits d4378c00 and ae456916 is truly important, and
definitely merits prominent mention in the press release. That'll
transform a query written as "SELECT * FROM tenk1 WHERE tenthous = 1
OR tenthous = 3 OR tenthous = 42 OR tenthous = 0" into a
representation that was previous only used when the query was written
"SELECT * FROM tenk1 WHERE tenthous IN (1,3,42,0)" (namely, it
transforms the original such that we can use the ScalarArrayOpExpr
representation).

This transformation is particularly useful in cases where it'll allow
us to get an index-only scan plan instead of a BitmapOr plan (with one
bitmap index scan child node for each of the 3 "tenthous" values from
the query), which is the only plan we could ever get on earlier
releases. The transformation process for these OR cases *can* work
with dynamic parameters (unlike the VALUES() stuff), and so can even
be used on the inner side of a join (see also commit 627d6341, which
dealt with making it possible to use OR transformation with joins).

Putting it all together, I suggest the following alternative:

"It can also automatically transform queries with `OR` constructs in
their `WHERE` clause into a logically equivalent IN() representation
that can be pushed down to index scan nodes, leading to significantly
faster execution".

--
Peter Geoghegan

On 9/9/25 11:38 PM, Peter Smith wrote:
> FWIW, here are a couple of AI-detected issues.
> 
> This typo:
> "with contains installers" should be "which contains installers"

Thanks!

> This potential mismatch:
> "Built on over 35 years of engineering" is inconsistent with the
> earlier "nearly 30 years" statement?

That actually needs updating, since it's nearly 40 years now. The first 
statement is on open source development, the second is on the overall 
lifetime of POSTGRES since Berkeley.

Jonathan

On 9/10/25 12:29 AM, jian he wrote:
> On Wed, Sep 10, 2025 at 11:13 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>
>> Hi,
>>
>> Please review for the press release for the following:
>>
>> * Correctness and accuracy of what's described - we want to be
>> technically correct, but we also need to explain why something matters
>> to our users.
> 
> PostgreSQL 18 adds [temporal
> constraints](https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-CONSTRAINTS)
> -- constraints over ranges -- for both `PRIMARY KEY` and `UNIQUE`
> constraints using the `WITHOUT OVERLAPS` clause, and on `FOREIGN KEY`
> constraints using the `PERIOD` clause.
> 
> this link (https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-CONSTRAINTS)
> seems not that appropriate, since it does not explain WITHOUT OVERLAPS,
> link (https://www.postgresql.org/docs/devel/sql-createtable.html#SQL-CREATETABLE-PARMS-UNIQUE)
> would be more appropriate?

I like the suggestion and made the swap. Thanks!

Jonathan

On 9/10/25 2:58 AM, Jakub Wartak wrote:

> and just leave it as
> "Finally, PostgreSQL 18 adds basic [NUMA observability]" ?
> 
> Rationale: for every other software that I saw NUMA awareness
> reference was always linked to gaining performance , but just linking
> against libnuma is not giving us this.

Hm, based on this I'm inclined to remove it. It's hard to explain a "so 
what" here, since the so what is that it's making it easier for us to 
perform this work below:

> * = with on going work for 19 (future Tomas's we'll get there I hope)

Thanks,

Jonathan

On 9/10/25 9:52 AM, John Naylor wrote:
> On Wed, Sep 10, 2025 at 10:13 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> 
>> PostgreSQL 18 also supports using x86 AVX-512 instructions for CRC32 calculations, which are used in page checksums
andare also available in the new
[`crc32`](https://www.postgresql.org/docs/18/functions-binarystring.html#FUNCTIONS-BINARYSTRING-OTHER)function.
 
> 
> Hi Jon,
> 
> The checksum stored in the page header is not actually a CRC but
> something else entirely. WAL records are a convenient example of
> something that uses CRC.
> 
> Also, CRC32 is not hardware accelerated, only CRC32C is. We have two
> SQL-callable functions.  To avoid confusion maybe they can be omitted
> from this longer-than-usual announcement -- they seem like a niche
> feature anyway.

Thanks; I've removed the reference.

Jonathan

On 9/10/25 3:59 PM, Peter Geoghegan wrote:

> "It can also automatically transform queries with `OR` constructs in
> their `WHERE` clause into a logically equivalent IN() representation
> that can be pushed down to index scan nodes, leading to significantly
> faster execution".

Thanks for the detailed explanation, I'm proposing:

"It can also optimize queries that use `OR` conditions in a `WHERE` to 
use an index, leading to significantly faster execution."

since the mechanism of the transformation is less important, but the 
outcome is that people can benefit from the previous optimziation 
without having to rewrite their queries.

Jonathan

On Thu, Sep 11, 2025 at 10:21 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Thanks for the detailed explanation, I'm proposing:
>
> "It can also optimize queries that use `OR` conditions in a `WHERE` to
> use an index, leading to significantly faster execution."
>
> since the mechanism of the transformation is less important, but the
> outcome is that people can benefit from the previous optimziation
> without having to rewrite their queries.

Sounds good.

Thanks
--
Peter Geoghegan

On 9/9/25 11:13 PM, Jonathan S. Katz wrote:
> Hi,
> 
> Attached is a draft of the PostgreSQL 18 GA press release. A few 
> comments before the ask for reviewing:
> 
> * I still need to write up the theme and the quote, which I'll provide 
> tomorrow after hearing the first round of feedback
> * The release is a bit long - this is due in part to what I think is a 
> lot of really good features in PostgreSQL 18. "Something for everyone"
> 
> Please review for the press release for the following:
> 
> * Correctness and accuracy of what's described - we want to be 
> technically correct, but we also need to explain why something matters 
> to our users.
> * Notable omissions (apologies if I missed something, but also note not 
> everything going to make the cut).
> * Features to exclude.
> * How easy phrases are to translate / confusing phrases
> * Typos.
> 
> Like previous years, I won't really look at stylistic remarks, unless it 
> falls into the "making it simpler to translate / confusing phrase" bucket.
> 
> After 2025-09-14 0:00 UTC I won't be able to accept more feedback, as 
> we'll need to begin the translation process. Anyone who provides 
> accepted feedback will also get a mention in the press release "thank 
> you" page[1], which stays up for about a year ;)

Thanks for all of your feedback thus far! Attached is the next version 
of the draft. This incorporates the feedback, and now includes the 
thematic statement and a draft quote.

As per above, I'll need remaining feedback no later than 2025-09-14 0:00 
UTC - after this, it's frozen for the translation process to begin.

Thanks!

Jonathan

On Tue, 2025-09-09 at 23:13 -0400, Jonathan S. Katz wrote:
> Hi,
>
> Attached is a draft of the PostgreSQL 18 GA press release. A few
> comments before the ask for reviewing:

"This release adds the [`PG_UNICODE_FAST`], which accelerates lookups
using the `upper` and `lower` string comparison functions, and helps
speed up the new [`casefold`] function for case-insensitive
comparisons."

Use the link:
https://www.postgresql.org/docs/18/collation.html#COLLATION-MANAGING-STANDARD
which is a bit more descriptive. (Though perhaps that document could be
improved with examples.)

What's actually new with PG_UNICODE_FAST are the "full" Unicode
semantics for case transformations, e.g. it uppercases 'ß' to 'SS'. The
rest is the same as PC_C_UTF8, which uses "simple" Unicode semantics.

The name PG_UNICODE_FAST is meant to convey that it provides full
unicode semantics for case mapping and pattern matching, while also
being fast because it uses memcmp for comparisons. While the name
PG_C_UTF8 is meant to convey that it's closer to what users of the libc
"C.UTF-8" locale might expect.

Regards,
    Jeff Davis

On Fri, Sep 12, 2025 at 8:46 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> On 9/9/25 11:13 PM, Jonathan S. Katz wrote:
> > Hi,
> >
> > Attached is a draft of the PostgreSQL 18 GA press release. A few
> > comments before the ask for reviewing:
> >
> > * I still need to write up the theme and the quote, which I'll provide
> > tomorrow after hearing the first round of feedback
> > * The release is a bit long - this is due in part to what I think is a
> > lot of really good features in PostgreSQL 18. "Something for everyone"
> >
> > Please review for the press release for the following:
> >
> > * Correctness and accuracy of what's described - we want to be
> > technically correct, but we also need to explain why something matters
> > to our users.
> > * Notable omissions (apologies if I missed something, but also note not
> > everything going to make the cut).
> > * Features to exclude.
> > * How easy phrases are to translate / confusing phrases
> > * Typos.
> >
> > Like previous years, I won't really look at stylistic remarks, unless it
> > falls into the "making it simpler to translate / confusing phrase" bucket.
> >
> > After 2025-09-14 0:00 UTC I won't be able to accept more feedback, as
> > we'll need to begin the translation process. Anyone who provides
> > accepted feedback will also get a mention in the press release "thank
> > you" page[1], which stays up for about a year ;)
>
> Thanks for all of your feedback thus far! Attached is the next version
> of the draft. This incorporates the feedback, and now includes the
> thematic statement and a draft quote.
>
> As per above, I'll need remaining feedback no later than 2025-09-14 0:00
> UTC - after this, it's frozen for the translation process to begin.
>

I found a typo;

s/gen_rand_uuid()/gen_random_uuid()/

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

On Fri, Sep 12, 2025 at 10:11:59AM -0700, Jeff Davis wrote:
> The name PG_UNICODE_FAST is meant to convey that it provides full
> unicode semantics for case mapping and pattern matching, while also
> being fast because it uses memcmp for comparisons. While the name
> PG_C_UTF8 is meant to convey that it's closer to what users of the libc
> "C.UTF-8" locale might expect.

How does one do form-insensitive comparisons?

Nico
-- 

On 9/12/25 2:18 PM, Masahiko Sawada wrote:

> 
> I found a typo;
> 
> s/gen_rand_uuid()/gen_random_uuid()/

Good catch - thanks!

Jonathan

On Fri, 2025-09-12 at 13:21 -0500, Nico Williams wrote:
> On Fri, Sep 12, 2025 at 10:11:59AM -0700, Jeff Davis wrote:
> > The name PG_UNICODE_FAST is meant to convey that it provides full
> > unicode semantics for case mapping and pattern matching, while also
> > being fast because it uses memcmp for comparisons. While the name
> > PG_C_UTF8 is meant to convey that it's closer to what users of the
> > libc
> > "C.UTF-8" locale might expect.
>
> How does one do form-insensitive comparisons?

If you mean case insensitive matching, you can do:

   CASEFOLD(a) = CASEFOLD(b)

in any locale or provider, but it's best when using PG_UNICODE_FAST or
ICU, because it handles some nuances better. For instance:

   CASEFOLD('ß') = CASEFOLD('SS') AND
   CASEFOLD('ß') = CASEFOLD('ss') AND
   CASEFOLD('ß') = CASEFOLD('ẞ')

are all true in PG_UNICODE_FAST and "en-US-x-icu", but not in libc
collations.

ICU also has case-insensitive collations, which offer a bit more
flexibility:

https://www.postgresql.org/docs/current/collation.html#COLLATION-NONDETERMINISTIC

Regards,
    Jeff Davis

Hello,

Thanks for putting this together!  It's quite the monster.  I read
through and found the following points worth mentioning:

I think almost all of the non-stock section titles Are Lacking Case
Title.

> The new [`io_method`](https://www.postgresql.org/docs/18/runtime-config-resource.html#GUC-IO-METHOD) setting lets you
togglebetween the AIO methods, including `worker` and `io_uring` (when built with PostgreSQL, available on certain
Linuxsystems), or you can choose to maintain the current PostgreSQL behavior with the `sync` setting. There are now
moreparameters to consider tuning with AIO, which you can [learn more about in the
documentation](https://www.postgresql.org/docs/18/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-IO).

I don't understand the "when built with PostgreSQL".  Did you mean to
reference something else here?

> PostgreSQL 18 further accelerates query performance with features that automatically make your workloads faster. This
releaseintroduces "skip scan" lookups on [multicolumn B-tree
indexes](https://www.postgresql.org/docs/18/indexes-multicolumn.html),which improves execution time for queries that
omitan `=` condition on one or more prefix index columns. It can also optimize queries that use `OR` conditions in a
`WHERE`to use an index, leading to significantly faster execution. There are also numerous improvements for how
PostgreSQLplans and executes table joins, from boosting the performance of hash joins to allowing merge joins to use
incrementalsorts. 

introduces "skip scan" lookups ..., which improve
(remove ending 's')

> PostgreSQL 18 now supports parallel builds for [GIN indexes](https://www.postgresql.org/docs/18/gin.html), joining
B-treeand [BRIN indexes](https://www.postgresql.org/docs/current/brin.html) in supporting this capability.
Additionally,[materialized views](https://www.postgresql.org/docs/18/rules-materializedviews.html) can now use unique
indexesthat aren't B-trees as partition keys, expanding how you can construct materialized views. 

Materialized views can use non-btree indexes as partition keys?  Sounds
cool, but the linked-to matview page doesn't talk about partitioning at
all.  I think there's something wrong with the way this has been
written.  [trawls the release notes]  Hmm, the release notes have this
text:

   "Allow non-btree unique indexes to be used as partition keys and in
   materialized views"

I think the confusion stems from having missed the "and" there.

Actually I wonder if these two items (commits f278e1fe3 and 9d6db8bec)
are actually worthy of being in the press release.  They are about using
unique indexes that aren't btrees, but as I understand, in stock
Postgres there isn't any other way to build unique indexes, so this is
about allowing out-of-core index AMs to be used in these contexts.


> PostgreSQL 18 makes text processing easier and faster with several new enhancements. This release adds the
[`PG_UNICODE_FAST`](https://www.postgresql.org/docs/18/locale.html#LOCALE-PROVIDERS),which accelerates lookups using
the`upper` and `lower` string comparison functions, and helps speed up the new
[`casefold`](https://www.postgresql.org/docs/18/functions-string.html#FUNCTIONS-STRING-OTHER)function for
case-insensitivecomparisons. Additionally, PostgreSQL 18 now supports making `LIKE` comparisons over text that uses a
[nondeterministiccollation](https://www.postgresql.org/docs/18/collation.html#COLLATION-NONDETERMINISTIC), simplifying
howyou can perform more complex pattern matching. This release also changes [full text
search](https://www.postgresql.org/docs/18/textsearch.html)to use the default collation provider of a cluster instead
ofalways using libc, which may require you to reindex all [full text
search](https://www.postgresql.org/docs/18/textsearch-tables.html#TEXTSEARCH-TABLES-INDEX)and
[`pg_trgm`](https://www.postgresql.org/docs/18/pgtrgm.html#PGTRGM-INDEX)indexes after running
[`pg_upgrade`](https://www.postgresql.org/docs/18/pgupgrade.html).

I think this should say "This release adds the PG_UNICODE_FAST local
provider", or something like that, because ending in just
"PG_UNICODE_FAST" seems to be unintelligible.

> ### Authentication and security features

In this section I would also mention that pgcrypto gained SHA-2 cipher
for passwords (commit 749a9e20c979).

> PostgreSQL 18 now supports reporting logical replication write conflicts in logs and in the
[`pg_stat_subscription_stats`](https://www.postgresql.org/docs/18/monitoring-stats.html#MONITORING-PG-STAT-SUBSCRIPTION-STATS)
view.Additionally, [`CREATE SUBSCRIPTION`](https://www.postgresql.org/docs/18/sql-createsubscription.html) now defaults
touse parallel streaming for applying transactions, which can help improve performance. The
[`pg_createsubscriber`](https://www.postgresql.org/docs/18/app-pgcreatesubscriber.html)now has an `--all` flag so you
cancreate logical replicas for all databases in an instance with a single command. PostgreSQL 18 also lets you
automatically[drop idle replication
slots](https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-IDLE-REPLICATION-SLOT-TIMEOUT)to help
preventstoring too many write-ahead log files on a publisher. 

My English grammar fails me here.  I would say "... now defaults to
using", but maybe your "now defaults to use" is correct.

"The pg_createsubscriber **utility**" ?

> Databases initialized with PostgreSQL 18 [`initdb`](https://www.postgresql.org/docs/18/app-initdb.html) now have page
checksumsenabled by default. This can affect upgrades from non-checksum enabled clusters, which would require you to
createa new PostgreSQL 18 cluster with the `--no-data-checksums` option when using
[`pg_upgrade`](https://www.postgresql.org/docs/18/pgupgrade.html).

I'm not sure that the relnotes really need to explain how to use
pg_upgrade.  To me it seems enough to say that initdb now creates
checksum-enabled clusters by default.


Thanks!

--
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)

On Fri, Sep 12, 2025 at 12:13:23PM -0700, Jeff Davis wrote:
> On Fri, 2025-09-12 at 13:21 -0500, Nico Williams wrote:
> > How does one do form-insensitive comparisons?
> 
> If you mean case insensitive matching, you can do:

I meant form-insensitive, as in comparing equivalent strings where one
might be using decomposed sequences and another pre-conposed sequences
(and either might be normalized or not at all).

Nico
-- 

On Fri, 2025-09-12 at 15:48 -0500, Nico Williams wrote:
> I meant form-insensitive, as in comparing equivalent strings where
> one
> might be using decomposed sequences and another pre-conposed
> sequences
> (and either might be normalized or not at all).

Use NORMALIZE(a) = NORMALIZE(b).

This is getting a little off-topic from what's actually being released,
so please reopen a more relevant thread or start a new one, and CC me.

Regards,
    Jeff Davis

On 9/12/25 1:11 PM, Jeff Davis wrote:
> On Tue, 2025-09-09 at 23:13 -0400, Jonathan S. Katz wrote:
>> Hi,
>>
>> Attached is a draft of the PostgreSQL 18 GA press release. A few
>> comments before the ask for reviewing:
> 
> "This release adds the [`PG_UNICODE_FAST`], which accelerates lookups
> using the `upper` and `lower` string comparison functions, and helps
> speed up the new [`casefold`] function for case-insensitive
> comparisons."
> 
> Use the link:
> https://www.postgresql.org/docs/18/collation.html#COLLATION-MANAGING-STANDARD
> which is a bit more descriptive. (Though perhaps that document could be
> improved with examples.)
> 
> What's actually new with PG_UNICODE_FAST are the "full" Unicode
> semantics for case transformations, e.g. it uppercases 'ß' to 'SS'. The
> rest is the same as PC_C_UTF8, which uses "simple" Unicode semantics.
> 
> The name PG_UNICODE_FAST is meant to convey that it provides full
> unicode semantics for case mapping and pattern matching, while also
> being fast because it uses memcmp for comparisons. While the name
> PG_C_UTF8 is meant to convey that it's closer to what users of the libc
> "C.UTF-8" locale might expect.

I went with breaking this up into two sentences:

This release adds the 
[`PG_UNICODE_FAST`](https://www.postgresql.org/docs/18/collation.html#COLLATION-MANAGING-STANDARD), 
which provides full Unicode semantics for case transformations while 
helping to accelerate many comparisons. This includes the `upper` and 
`lower` string comparison functions and the new 
[`casefold`](https://www.postgresql.org/docs/18/functions-string.html#FUNCTIONS-STRING-OTHER) 
function for case-insensitive comparisons.

Jonathan

On 9/12/25 3:24 PM, Álvaro Herrera wrote:
> Hello,
> 
> Thanks for putting this together!  It's quite the monster.  I read
> through and found the following points worth mentioning:

Thank you!

> I think almost all of the non-stock section titles Are Lacking Case
> Title.

Putting this is as an example of "stylistic comment" ;)

>> The new [`io_method`](https://www.postgresql.org/docs/18/runtime-config-resource.html#GUC-IO-METHOD) setting lets
youtoggle between the AIO methods, including `worker` and `io_uring` (when built with PostgreSQL, available on certain
Linuxsystems), or you can choose to maintain the current PostgreSQL behavior with the `sync` setting. There are now
moreparameters to consider tuning with AIO, which you can [learn more about in the
documentation](https://www.postgresql.org/docs/18/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-IO).
> 
> I don't understand the "when built with PostgreSQL".  Did you mean to
> reference something else here?

I re-read it and realized it doesn't add much value, so I just removed it.

>> PostgreSQL 18 further accelerates query performance with features that automatically make your workloads faster.
Thisrelease introduces "skip scan" lookups on [multicolumn B-tree
indexes](https://www.postgresql.org/docs/18/indexes-multicolumn.html),which improves execution time for queries that
omitan `=` condition on one or more prefix index columns. It can also optimize queries that use `OR` conditions in a
`WHERE`to use an index, leading to significantly faster execution. There are also numerous improvements for how
PostgreSQLplans and executes table joins, from boosting the performance of hash joins to allowing merge joins to use
incrementalsorts.
 
> 
> introduces "skip scan" lookups ..., which improve
> (remove ending 's')

Good catch - I revised and s/, which/that/

> Actually I wonder if these two items (commits f278e1fe3 and 9d6db8bec)
> are actually worthy of being in the press release.  They are about using
> unique indexes that aren't btrees, but as I understand, in stock
> Postgres there isn't any other way to build unique indexes, so this is
> about allowing out-of-core index AMs to be used in these contexts.

Thanks for the analysis on this one. Upon reflection, I'm going to 
remove this item from the press release. I'll move the parallel GIN 
builds to the first paragraph.

> I think this should say "This release adds the PG_UNICODE_FAST local
> provider", or something like that, because ending in just
> "PG_UNICODE_FAST" seems to be unintelligible.

Heh, should have added "collation"; fixed.

>> ### Authentication and security features
> 
> In this section I would also mention that pgcrypto gained SHA-2 cipher
> for passwords (commit 749a9e20c979).

Cool - added:

Additionally, 
[`pgcrypto`](https://www.postgresql.org/docs/18/pgcrypto.html) now 
supports [SHA-2 encryption for password 
hashing](https://www.postgresql.org/docs/18/pgcrypto.html#PGCRYPTO-CRYPT-ALGORITHMS).

> My English grammar fails me here.  I would say "... now defaults to
> using", but maybe your "now defaults to use" is correct.

I'm OK to use "using" if it's simpler for translating.

> "The pg_createsubscriber **utility**" ?

Thanks; I thought I had that in originally.

>> Databases initialized with PostgreSQL 18 [`initdb`](https://www.postgresql.org/docs/18/app-initdb.html) now have
pagechecksums enabled by default. This can affect upgrades from non-checksum enabled clusters, which would require you
tocreate a new PostgreSQL 18 cluster with the `--no-data-checksums` option when using
[`pg_upgrade`](https://www.postgresql.org/docs/18/pgupgrade.html).
> 
> I'm not sure that the relnotes really need to explain how to use
> pg_upgrade.  To me it seems enough to say that initdb now creates
> checksum-enabled clusters by default.

I included it because I think this is a potential tripwire. I don't know 
what the universe of non-checksum enabled clusters is out there, but I 
expect that it's pretty large. I think this is helpful for folks who are 
less familiar with PostgreSQL operational and upgrade mechanics (after 
all, they may only upgrade once a year at best) so it's a little simple 
to discover. Plus, this will help to surface the method as something to 
note through whatever AI summarizing techniques people are using.

Thanks!

Jonathan

On Sun, 2025-09-14 at 09:41 -0400, Jonathan S. Katz wrote:
> I went with breaking this up into two sentences:
>
> This release adds the
> [`PG_UNICODE_FAST`](
> https://www.postgresql.org/docs/18/collation.html#COLLATION-MANAGING-
> STANDARD),
> which provides full Unicode semantics for case transformations while
> helping to accelerate many comparisons. This includes the `upper` and
> `lower` string comparison functions and the new
> [`casefold`](
> https://www.postgresql.org/docs/18/functions-string.html#FUNCTIONS-
> STRING-OTHER)
> function for case-insensitive comparisons.

Perfect, thank you.

Regards,
    Jeff Davis

On 9/12/25 11:46 AM, Jonathan S. Katz wrote:

> As per above, I'll need remaining feedback no later than 2025-09-14 0:00 
> UTC - after this, it's frozen for the translation process to begin.

Thank everyone for your feedback. I've attached the copy of the release 
announcement that will be translated and distributed. This is now frozen.

Thanks!

Jonathan