agora inbox for pgsql-docs@postgresql.org
help / color / mirror / Atom feedE.6.3.2.1. Constraints
5+ messages / 4 participants
[nested] [flat]
* E.6.3.2.1. Constraints
@ 2026-09-19 14:49 PG Doc comments form <noreply@postgresql.org>
2026-09-21 19:08 ` Re: E.6.3.2.1. Constraints Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 5+ messages in thread
From: PG Doc comments form @ 2026-09-19 14:49 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: kacperkuras@hotmail.com
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/18/release-18.html
Description:
Commit 086c84b23 changed what a foreign key with ON DELETE RESTRICT or ON
UPDATE RESTRICT raises when it refuses a change: SQLSTATE 23001
(restrict_violation) instead of 23503 (foreign_key_violation), and the
message now says "violates RESTRICT setting of foreign key constraint". The
PostgreSQL 18 release notes do not mention it.
Code that catches 23503 to report that a row is still referenced stops
matching RESTRICT keys after upgrading, while NO ACTION keys still raise
23503. The same notes list the change to the XML error codes (cd838e200), so
this one seems to belong there as well.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: E.6.3.2.1. Constraints
2026-09-19 14:49 E.6.3.2.1. Constraints PG Doc comments form <noreply@postgresql.org>
@ 2026-09-21 19:08 ` Bruce Momjian <bruce@momjian.us>
2026-09-22 05:51 ` Re: E.6.3.2.1. Constraints Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Momjian @ 2026-09-21 19:08 UTC (permalink / raw)
To: kacperkuras@hotmail.com; pgsql-docs@lists.postgresql.org
tOn Sat, Sep 19, 2026 at 02:49:55PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/18/release-18.html
> Description:
>
> Commit 086c84b23 changed what a foreign key with ON DELETE RESTRICT or ON
> UPDATE RESTRICT raises when it refuses a change: SQLSTATE 23001
> (restrict_violation) instead of 23503 (foreign_key_violation), and the
> message now says "violates RESTRICT setting of foreign key constraint". The
> PostgreSQL 18 release notes do not mention it.
>
> Code that catches 23503 to report that a row is still referenced stops
> matching RESTRICT keys after upgrading, while NO ACTION keys still raise
> 23503. The same notes list the change to the XML error codes (cd838e200), so
> this one seems to belong there as well.
How do we want to handle such cases in the release notes? The new codes
are not mentioned in the commit message, and there are no doc changes in the
patch. We have a similar commit from August, which was later reverted:
commit c16a1b4f2ce
Author: Peter Eisentraut <peter@eisentraut.org>
Date: Fri Aug 21 13:55:58 2026 +0200
Fix error code for null FOR PORTION OF target
When the target expression of FOR PORTION OF (...) evaluated to NULL,
ExecInitModifyTable raised an error without an errcode, so clients got
the internal error code XX000 for a user-reachable condition.
Oversight in commit 8e72d914c52.
To fix, report ERRCODE_NULL_VALUE_NOT_ALLOWED, and reword the message
to "FOR PORTION OF target must not be null", matching similar executor
messages such as "frame starting offset must not be null".
Bug: #19630
Reported-by: Zheng Wang <hackerzheng666@gmail.com>
Reported-by: Yanjie Zhao
Reported-by: Yiyang Liu
Author: Zsolt Parragi <zsolt.parragi@percona.com>
Discussion: https://www.postgresql.org/message-id/flat/19630-9f10ca28426295fa%40postgresql.org
--
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.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: E.6.3.2.1. Constraints
2026-09-19 14:49 E.6.3.2.1. Constraints PG Doc comments form <noreply@postgresql.org>
2026-09-21 19:08 ` Re: E.6.3.2.1. Constraints Bruce Momjian <bruce@momjian.us>
@ 2026-09-22 05:51 ` Laurenz Albe <laurenz.albe@cybertec.at>
2026-09-22 06:37 ` Re: E.6.3.2.1. Constraints Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 5+ messages in thread
From: Laurenz Albe @ 2026-09-22 05:51 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; kacperkuras@hotmail.com; pgsql-docs@lists.postgresql.org
On Mon, 2026-09-21 at 15:08 -0400, Bruce Momjian wrote:
> On Sat, Sep 19, 2026 at 02:49:55PM +0000, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/18/release-18.html
> > Description:
> >
> > Commit 086c84b23 changed what a foreign key with ON DELETE RESTRICT or ON
> > UPDATE RESTRICT raises when it refuses a change: SQLSTATE 23001
> > (restrict_violation) instead of 23503 (foreign_key_violation), and the
> > message now says "violates RESTRICT setting of foreign key constraint". The
> > PostgreSQL 18 release notes do not mention it.
> >
> > Code that catches 23503 to report that a row is still referenced stops
> > matching RESTRICT keys after upgrading, while NO ACTION keys still raise
> > 23503. The same notes list the change to the XML error codes (cd838e200), so
> > this one seems to belong there as well.
>
> How do we want to handle such cases in the release notes? The new codes
> are not mentioned in the commit message, and there are no doc changes in the
> patch.
In my opinion, that should have a place in the "migration to v19" section of
incompatibilities in the release notes.
I have no right to burden committers even more, but I'd say that such changes
should be part of the commit message.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: E.6.3.2.1. Constraints
2026-09-19 14:49 E.6.3.2.1. Constraints PG Doc comments form <noreply@postgresql.org>
2026-09-21 19:08 ` Re: E.6.3.2.1. Constraints Bruce Momjian <bruce@momjian.us>
2026-09-22 05:51 ` Re: E.6.3.2.1. Constraints Laurenz Albe <laurenz.albe@cybertec.at>
@ 2026-09-22 06:37 ` Daniel Gustafsson <daniel@yesql.se>
2026-09-22 13:40 ` Re: E.6.3.2.1. Constraints Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Gustafsson @ 2026-09-22 06:37 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Bruce Momjian <bruce@momjian.us>; Kacper Kuras <kacperkuras@hotmail.com>; pgsql-docs@lists.postgresql.org
> On 22 Sep 2026, at 07:51, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> I have no right to burden committers even more, but I'd say that such changes
> should be part of the commit message.
Not commenting on the specific commit or change here, but in general I think it
would be good if we started adding incompatabilities and upgrade notes to the
release notes over the development cycle rather than trying to collect them at
the end. It's fine to add a rough text which can be copy edited (or even
removed if deemed too minor) as the release notes process takes place, but
having it in the same commit as the change should ideally mean less work at the
end of the cycle and fewer missed notes.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: E.6.3.2.1. Constraints
2026-09-19 14:49 E.6.3.2.1. Constraints PG Doc comments form <noreply@postgresql.org>
2026-09-21 19:08 ` Re: E.6.3.2.1. Constraints Bruce Momjian <bruce@momjian.us>
2026-09-22 05:51 ` Re: E.6.3.2.1. Constraints Laurenz Albe <laurenz.albe@cybertec.at>
2026-09-22 06:37 ` Re: E.6.3.2.1. Constraints Daniel Gustafsson <daniel@yesql.se>
@ 2026-09-22 13:40 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 5+ messages in thread
From: Bruce Momjian @ 2026-09-22 13:40 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Kacper Kuras <kacperkuras@hotmail.com>; pgsql-docs@lists.postgresql.org
On Tue, Sep 22, 2026 at 08:37:42AM +0200, Daniel Gustafsson wrote:
> > On 22 Sep 2026, at 07:51, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> > I have no right to burden committers even more, but I'd say that such changes
> > should be part of the commit message.
>
> Not commenting on the specific commit or change here, but in general I think it
> would be good if we started adding incompatibilities and upgrade notes to the
> release notes over the development cycle rather than trying to collect them at
> the end. It's fine to add a rough text which can be copy edited (or even
> removed if deemed too minor) as the release notes process takes place, but
> having it in the same commit as the change should ideally mean less work at the
> end of the cycle and fewer missed notes.
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 wonder if this should be discussed on hackers instead?
--
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.
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-09-22 13:40 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-19 14:49 E.6.3.2.1. Constraints PG Doc comments form <noreply@postgresql.org>
2026-09-21 19:08 ` Bruce Momjian <bruce@momjian.us>
2026-09-22 05:51 ` Laurenz Albe <laurenz.albe@cybertec.at>
2026-09-22 06:37 ` Daniel Gustafsson <daniel@yesql.se>
2026-09-22 13:40 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox