Re: PG 18 beta1 release notes misses mention of pg_noreturn

On Mon, Jul 28, 2025 at 02:54:52PM -0400, Bruce Momjian wrote:
> On Mon, Jul 28, 2025 at 03:06:23PM +0200, Daniel Gustafsson wrote:
>> I totally agree that the release notes cannot contain all changes, and lot's of
>> important changes must be left out to make them manageable (the proposed change
>> here might well be one such change), but a blanket no for extension authors
>> seem counterproductive given how valuable they are to our ecosystem. A "what
>> would you like from the documentation" session at the next extension author
>> summit would be probably be interesting for getting insights into what is
>> missing and what could be improved.
>
> There is no clear boundry on what extension authors should see in the
> main release notes vs. seeing all changes that affect extensions, so I
> have never tried to include them.

IMO, I don't see any additional value in mentioning such changes in
the release notes. First, the line of what should or should not be
included is blurry: we break published APIs that extensions can
consume every release, and most of them are unlikely going to matter
if working on a dedicated extension.

Speaking from some personal experience about the case of pg_noreturn
(literally four days ago). While updating some of my template modules
published at [1] with Postgres 18, the switch from
pg_attribute_noreturn() to pg_noreturn can be noticed once you try to
compile background workers because these just break. It took me I
think a total of 5 minutes to find out that worker_spi/ was changed in
3691edfab971 to accomodate with the new flag, and that the same change
was required in my tree. Looking at the release notes would have been
likely longer, and the change is immediately noticeable once
compilation is tried.

Most of the ABI changes are like that, speaking from my own
experience: one cannot see the changes until they put their hands
down on the code. Of course, some of them are more painful depending
on the complexity of your extension code, and perhaps I am just more
experienced than others with the PG tree, but it is not really
possible to track how things break until you put your head down.
Release notes documenting a portion of these C-level changes don't
bring much value. I suspect that anybody who maintains extension code
does the same as I do. Even if the changes are listed, I would not
really need them. So that would just be more work for Bruce with what
I foresee as limited gain for the end-user. My 2c.

(Thanks for taking the time to compile the release notes every year
btw, Bruce.)

[1]: https://github.com/michaelpq/pg_plugins/
--
Michael