Subject: Re: PostgreSQL 19 beta 1 release announcement draft

From: Darren Duncan <[email-masked]>
Date: Fri, 29 May 2026 17:42:28 -0700

On 2026-05-29 9:46 a.m., Robert Haas wrote:
> I do feel like this release announcement (like others you've written)
> is extremely dense, and if I were writing it myself I would probably
> mention somewhat fewer things so that the things I did mention hit
> harder, but of course I'm not: you are. I also understand that gets
> into tough arguments about what's actually worth mentioning, which are
> inevitably subjective. Still, I'd suggest as a zero-order guideline
> that including things that are <~ 500 LOC is more likely to be clutter
> than a true headline feature.
I find that a general thing which makes it easier to say things less verbosely 
is if the less verbose work can include a link to a version with more details, 
eg the full release notes, so nothing is actually being lost, just kept in a 
different place. -- Darren Duncan

---

From: Jacob Champion <[email-masked]>
Date: Mon, 1 Jun 2026 15:12:11 -0700

On Thu, May 28, 2026 at 8:23 PM Jonathan S. Katz <[email-masked]> wrote:
> Attached is the draft of the PostgreSQL 19 Beta 1 release announcement.
> Please review for accuracy (e.g. are features described correctly? Did I
> miss a revert), recommendations on additions or glaring omissions,
> structure, etc.

I think the beta announcement should probably reference the grease
campaign [1], since it'll only be conducted during 19beta, and we want
to encourage testers to try to find and report failures. I don't know
if that should be in the Testing section, or on the beta page of the
site, or somewhere else.

On Fri, May 29, 2026 at 9:46 AM Robert Haas <[email-masked]> wrote:
> I also understand that gets

If we're looking to streamline, I'll be the first to offer up
PQAUTHDATA_OAUTH_BEARER_TOKEN_V2 for the chopping block. :D
Alternatively, it could be pulled into a generic summary in the Other
Highlights section, like "OAuth support has received several
quality-of-life improvements for client and server developers" (which
also credits the other community contributions in that area, some of
which are more substantial than the new flow type).

If we do keep it where it is, I think "structured error message
specification" should be replaced with something like "custom error
messages". The structured-error wording makes me think of things like
error templates and JSON.

Thanks!
--Jacob

[1] https://wiki.postgresql.org/wiki/Grease

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Mon, 1 Jun 2026 22:01:15 -0400

> than a true headline feature.
first, thank you (and everyone!) for the reviws.

I'll reply / incorporate the other comments (+ other replies) on the 
thread separately, but wanted to address this one specifically.

Specifically for beta, I think we need to optimize for discoverability, 
one for testing purposes, but to make people generally aware what's 
available. The difference between the announcements and the release 
notes is that the announcements can give more context to the features 
and why they matter. In the past, we've had issues where we've missed 
things that have had significant user impact, so I've biased to be more 
verbose vs. less.

Now, if it's unintelligible because there's too much in there, or we 
need to make room for other things that's fine. OTOH, if we're in the 
"agenetic summarization" world, to me it seems better to put more detail 
into the release announcement.

Flipping back to the GA I think your point does stand with an asterisk - 
I think we can make those more focused and expand on a few different 
features, but I do want to save that discussion for when we ramp up that 
portion of the release cycle.

Thanks,

Jonathan

---

From: Darren Duncan <[email-masked]>
Date: Mon, 1 Jun 2026 21:11:08 -0700

On 2026-06-01 7:01 p.m., Jonathan S. Katz wrote:
> The 
> difference between the announcements and the release notes is that the 
> announcements can give more context to the features and why they matter. In the 
> past, we've had issues where we've missed things that have had significant user 
> impact, so I've biased to be more verbose vs. less.
On that note, I feel the release notes are best to be a superset of the 
announcements, such that any verbiage written for announcements like the context 
and why things matter, that should be copied into the release notes so people 
reading the release notes also have that helpful information. -- Darren Duncan

---

From: Miaolai Zhou <[email-masked]>
Date: Tue, 2 Jun 2026 10:36:06 -0400

Thanks you, Jonathan! Here's my feedback:

1. Broken link: The PostgreSQL 19 docs link
(https://www.postgresql.org/docs/19/release-19.html) is showing "Page
not found".

2. Move the call-to-action up: I'd suggest moving "Testing for Bugs &
Compatibility" closer to the top of the announcement. Since many
readers don't make it to the end, we might lose them before they see
how they can help. We could then echo it again at the end to reinforce
how valuable community testing is.

3. Consider adding a feature summary table: What do you think about
including a table that lists the key features with one-line summaries,
then linking to the detailed paragraphs? It would add some length, but
it could help readers quickly scan and jump to what interests them
most.

Thanks,

Miaolai (Mila) Zhou

On Thu, May 28, 2026 at 11:23 PM Jonathan S. Katz <[email-masked]> wrote:
> Hi,
> Please provide feedback no later than June 4, 2026 12:00 UTC (though
> preferably earlier!)
>
> Thanks,
>
> Jonathan

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 3 Jun 2026 13:13:36 -0400

(for individual replies, I'll be commenting on specific areas that have 
some form of follow-up; otherwise I'm accepting/rejecting suggestions. 
Thanks!)

On 5/29/26 12:45 PM, Greg Sabino Mullane wrote:

> 
>  > that lets table scans mark pages as visible
> 
> This sentence trips me up mentally each time I read it. Not sure of a 
> solution.

I took another read - I expanded on it a bit but made it sound less 
PostgreSQL inside knowledge specific:

==
PostgreSQL 19 further enhances vacuum with a new strategy that can 
automatically reduce future vacuuming work by using making optimizations 
while queries are executing.
==

>  > making it easier to use logical replication for use cases like upgrades
> 
> making it easier for upgrades

Opted for:

==
In PostgreSQL 19, logical replication now replicates sequence values,
simplifying tasks like online upgrades.
==

Thanks!

Jonathan

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 3 Jun 2026 13:20:04 -0400

On 5/29/26 12:46 PM, Robert Haas wrote:
> I asked Claude to analyze this for things that were missing. It
> mentioned these as things that should possibly be mentioned: INSERT ON
> CONFLICT SELECT, eager aggregation, IGNORE NULLS for window functions,
> pg_dumpall for non-text formats. Of those, I would personally judge
> eager aggregation to be the most significant.
> 
> It also pointed out that the bit about GRANTED BY is misleading,
> because the syntax already existed, and already worked for roles.
> What's different is that for non-roles, it now can be used with values
> other than CURRENT_USER/CURRENT_ROLE and actually do something. It
> suggested that this was actually too minor to be included in a release
> note draft. I agree -- it's a small patch to fill a gap that few
> people will ever really be troubled by. Of course it will be useful to
> those who do run into it, but it's not really a headline feature IMHO.
Thanks - that was helpful. I went with:

* including INSERT ON CONFLICT SELECT RETURNING and eager aggregation
* removing the GRANTED BY section

I'll post the updated copy at the top of the thread shortly as I work 
through the rest of the feedback and add in the relevant links.

Thanks,

Jonathan

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 3 Jun 2026 13:34:16 -0400

> if that should be in the Testing section, or on the beta page of the

Thanks, I do think we should include this. I've added this blurb, please 
LMK what you think:

==
The PostgreSQL 19 beta period includes a [grease 
campaign](https://wiki.postgresql.org/wiki/Grease) to help improve how 
clients interact with the PostgreSQL server. This wiki page contains 
information on how the campaign works, and how to make the appropriate 
modifications to clients as part of the campaign:

https://wiki.postgresql.org/wiki/Grease
==

> which are more substantial than the new flow type).
I opted for the simplification aspect, i.e. dropping it. I'd like to 
noodle on if/how to advertise the quality of life improvement aspects in 
the GA, but I'll take that as an exercise for August.

Jonathan

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 3 Jun 2026 13:37:33 -0400

Hi Mila,

> (https://www.postgresql.org/docs/19/release-19.html) is showing "Page

This will be fixed when we perform the release; right now it's a 
placeholder.

> it could help readers quickly scan and jump to what interests them
I wonder if we do this for the GA? Open to thoughts here.

Thanks,

Jonathan

---

From: Jacob Champion <[email-masked]>
Date: Wed, 3 Jun 2026 11:42:07 -0700

> https://wiki.postgresql.org/wiki/Grease

My counter would be something like

    The PostgreSQL 19 beta period includes a temporary "grease mode"
to try to find protocol compatibility problems in the wider ecosystem.
This wiki page contains information on how the campaign works:

Thanks!
--Jacob

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 3 Jun 2026 20:54:43 -0400

Hi,

> Please provide feedback no later than June 4, 2026 12:00 UTC (though 
Thanks again for all the feedback. Here's the current copy; I'm working 
on adding in links to the docs to it.

Thanks,

Jonathan

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 3 Jun 2026 20:55:35 -0400

On 6/3/26 8:54 PM, Jonathan S. Katz wrote:
>> Attached is the draft of the PostgreSQL 19 Beta 1 release 
>> announcement. Please review for accuracy (e.g. are features described 
>> correctly? Did I miss a revert), recommendations on additions or 
>> glaring omissions, structure, etc.
>>
And here's the actual current copy.

Jonathan