PostgreSQL 19 Beta 1 Release Announcement Draft Review

Overview

This thread concerns the community review of the PostgreSQL 19 Beta 1 release announcement draft, a standard part of the PostgreSQL release process where the announcement text is circulated for accuracy checking and feedback on feature presentation. The thread reveals interesting insights into which PostgreSQL 19 features the community considers most impactful and how they should be communicated to users.

The Core Task

Release announcements serve dual purposes: they inform existing users about upgrade-worthy features, and they market PostgreSQL to potential adopters. The ordering and framing of features in the announcement is therefore a strategic communication decision, not merely a technical documentation exercise. Jonathan Katz (a PostgreSQL Core Team member and major contributor to release communications) circulated the draft with a tight review window (approximately 6 days).

Key Feature Discussions

pg_plan_advice — Promotion in Announcement Priority

Jakub Wartak's recommendation to elevate pg_plan_advice in the announcement reflects real-world operational pain. This feature (likely providing plan hints or guidance functionality) addresses a long-standing gap in PostgreSQL relative to commercial databases like Oracle and SQL Server. The argument is compelling from both a migration perspective (users refusing to migrate from Oracle due to lack of hint-like functionality) and an operational perspective (emergency situations where query plans go wrong in production).

The fact that this feature exists in PostgreSQL 19 at all represents a significant philosophical shift — PostgreSQL has historically resisted optimizer hints, preferring the optimizer to make correct decisions autonomously. That pg_plan_advice made it into the release suggests the community found an acceptable middle ground, and Wartak's feedback suggests it deserves prominent placement to signal this shift.

64-bit MultiXactOffset

This is a deeply architectural improvement that addresses one of PostgreSQL's most dangerous operational failure modes. The MultiXact system tracks shared row locks (commonly triggered by foreign key checks in concurrent workloads). Prior to this change, the 32-bit MultiXact member offset counter could wrap around, triggering emergency anti-wraparound vacuums that could freeze entire systems.

Wartak's suggested phrasing — emphasizing prevention of "emergency anti-wraparound vacuums previously caused by highly concurrent workloads involving FKs" — correctly identifies the user-facing impact. This is analogous to the earlier expansion of transaction IDs and is part of PostgreSQL's ongoing effort to eliminate wraparound-related failure modes. For high-concurrency OLTP workloads with extensive foreign key relationships, this eliminates a class of production incidents entirely.

GROUP BY ALL

Both reviewers independently suggested adding GROUP BY ALL to the announcement under Developer Experience. This SQL syntactic convenience (automatically grouping by all non-aggregate columns in the SELECT list) is a quality-of-life improvement popular in modern analytical SQL dialects (DuckDB, BigQuery, etc.). Its omission from the draft suggests it may have been considered too minor, but the dual independent recommendations indicate community consensus that it's announcement-worthy.

jsonpath String Functions

Florents Tselai suggested improved phrasing for the jsonpath enhancements, specifically the addition of lower(), upper(), initcap(), replace(), split_part(), and the trim() family. This extends PostgreSQL's JSON processing capabilities, bringing jsonpath closer to feature parity with regular string processing. The suggested phrasing ("extends string processing capabilities in jsonpath") better frames the enhancement as a coherent capability expansion rather than a list of individual functions.

Communication Strategy Observations

The feedback reveals a tension in release announcement drafting:

1. Operational significance vs. feature novelty: The 64-bit MultiXactOffset change is architecturally significant but may seem dry; proper framing emphasizes the production incidents it prevents.
2. Migration enablement: pg_plan_advice may be the single most important migration-enabling feature for Oracle/SQL Server shops, warranting prominent placement.
3. Developer appeal: GROUP BY ALL and jsonpath improvements attract developers from modern data tools ecosystems (DuckDB, etc.).

Process Notes

The review window (May 29 to June 4, 2026) is typical for PostgreSQL beta announcements, giving approximately one week for community feedback before the beta release. The beta release itself triggers a broader testing period where the community validates features before the final release (typically in the fall).