PG 18 beta1 release notes misses mention of pg_noreturn
Hello hackers,
While updating an extension to support 18beta1, I stumbled on the removal
of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't
mentioned in the release notes.
I've attached a patch for fixing this.
Best regards,
Steve Chavez
Attachments:
0001-doc-PG-18-relnotes-mention-of-pg_noreturn.patchtext/x-patch; charset=US-ASCII; name=0001-doc-PG-18-relnotes-mention-of-pg_noreturn.patchDownload+7-1
On 2 Jul 2025, at 04:51, Steve Chavez <steve@supabase.io> wrote:
While updating an extension to support 18beta1, I stumbled on the removal of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't mentioned in the release notes.
That admittedly seems like something worth including since it's otherwise not
documented anywhere.
--
Daniel Gustafsson
Yes, otherwise I had to grep the commits in `git log` and find what's the
correct way to use `pg_noreturn`.
It's not a simple keyword replacement since the order has to change now:
Old: void my_worker(Datum main_arg) pg_attribute_noreturn();
New: pg_noreturn void my_worker(Datum main_arg);
I've added the link to the commit in the patch, which should be enough to
infer the above.
How can I get this committed? Is the hacker mailing list the right place
for release notes correction?
Best regards,
Steve Chavez
On Wed, 2 Jul 2025 at 11:24, Daniel Gustafsson <daniel@yesql.se> wrote:
Show quoted text
On 2 Jul 2025, at 04:51, Steve Chavez <steve@supabase.io> wrote:
While updating an extension to support 18beta1, I stumbled on the
removal of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which
wasn't mentioned in the release notes.That admittedly seems like something worth including since it's otherwise
not
documented anywhere.--
Daniel Gustafsson
On Thu, Jul 3, 2025 at 8:08 PM Steve Chavez <steve@supabase.io> wrote:
Yes, otherwise I had to grep the commits in `git log` and find what's the correct way to use `pg_noreturn`.
It's not a simple keyword replacement since the order has to change now:Old: void my_worker(Datum main_arg) pg_attribute_noreturn();
New: pg_noreturn void my_worker(Datum main_arg);
I've added the link to the commit in the patch, which should be enough to infer the above.
How can I get this committed? Is the hacker mailing list the right place for release notes correction?
This is the right place to discuss this. Please add your patch to the
commitfest App. https://commitfest.postgresql.org/. The landing page
has a useful link for first timers.
Best regards,
Steve Chavez
Please do not top-post, reply inline as I have done.
--
Best Wishes,
Ashutosh Bapat
On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
On 2 Jul 2025, at 04:51, Steve Chavez <steve@supabase.io> wrote:
While updating an extension to support 18beta1, I stumbled on the removal of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't mentioned in the release notes.
That admittedly seems like something worth including since it's otherwise not
documented anywhere.
I don't add changes to the release notes that would only affect
extension authors because there are many such changes, and such changes
would be meaningless to non-extension authors. If we want to document
this, we would need an extension-author specific release notes list.
--
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 25 Jul 2025, at 00:22, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
On 2 Jul 2025, at 04:51, Steve Chavez <steve@supabase.io> wrote:
While updating an extension to support 18beta1, I stumbled on the removal of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't mentioned in the release notes.
That admittedly seems like something worth including since it's otherwise not
documented anywhere.I don't add changes to the release notes that would only affect
extension authors because there are many such changes, and such changes
would be meaningless to non-extension authors. If we want to document
this, we would need an extension-author specific release notes list.
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.
--
Daniel Gustafsson
On Mon, Jul 28, 2025 at 03:06:23PM +0200, Daniel Gustafsson wrote:
On 25 Jul 2025, at 00:22, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
On 2 Jul 2025, at 04:51, Steve Chavez <steve@supabase.io> wrote:
While updating an extension to support 18beta1, I stumbled on the removal of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't mentioned in the release notes.
That admittedly seems like something worth including since it's otherwise not
documented anywhere.I don't add changes to the release notes that would only affect
extension authors because there are many such changes, and such changes
would be meaningless to non-extension authors. If we want to document
this, we would need an extension-author specific release notes list.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.
--
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 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]https://github.com/michaelpq/pg_plugins/ -- Michael 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
--
Michael