Re: E.6.3.2.1. Constraints - Mailing list pgsql-docs

From David Rowley
Subject Re: E.6.3.2.1. Constraints
Date
Msg-id CAApHDvqBZgFGWSRnpwcFKxQ2_maKs0ujW-f=UjhGd567uY8q+g@mail.gmail.com
Whole thread
In response to Re: E.6.3.2.1. Constraints  (Bruce Momjian <bruce@momjian.us>)
List pgsql-docs
On Wed, 23 Sept 2026 at 01:40, Bruce Momjian <bruce@momjian.us> wrote:
> Actually, many committers already mark incompatibilities and mention the
> release notes in their commit messages.  My question here is whether
> error code changes are incompatibilities worthy of being mentioned in
> the release notes, and if committers don't mention this in the commit
> message, how would I find them when creating the release notes?

I think error code changes are worthy of a release note mention.
People doing light testing of applications on newer versions might not
notice the broken error handling because error conditions might be
rare. This particular one may need a concurrent user to update a
record, so a breakage might not be noticed easily.

Not sure about the committers part. What would catch your attention
the best? A new tag? or mentioning "release notes" in the commit
message? Despite the odd typo, committers seem to be quite good at
using tags. They stand out quite well and it's easy to see what others
do and copy that. This one might only appear rarely, so it might not
work quite as well.  Mentioning it in
https://wiki.postgresql.org/wiki/Commit_Message_Guidance would likely
help.

If the committer neglects to do that, I don't think you can be
expected to figure all these out from looking at the code changes.
Doing the release notes looks like a hard enough job already.

> I wonder if this should be discussed on hackers instead?

Probably.

David



pgsql-docs by date:

Previous
From: Kacper Kuras
Date:
Subject: Re: E.6.3.2.1. Constraints
Next
From: Thom Brown
Date:
Subject: Fixes for create subscription page