Re: Fix bug of CHECK constraint enforceability recursion
jian he <jian.universality@gmail.com>
From: jian he <jian.universality@gmail.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, "L. pgsql-hackers" <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>
Date: 2026-05-26T08:32:29Z
Lists: pgsql-hackers
Attachments
On Tue, May 26, 2026 at 3:47 PM Chao Li <li.evan.chao@gmail.com> wrote:
>
> >
> > I think this is a bug that we need to fix in 19 as well — I mean we should reject the ALTER TABLE.
> >
> > --
> > Álvaro Herrera
>
> Thanks for your comment. Let me rework the patch.
>
Hi.
Here are the comments placed in ATExecAlterCheckConstrEnforceability I
came up with:
+ /*
+ * If the check constraint qual definitions match but their enforcement
+ * statuses conflict (parent enforced, child unenforced), it creates
+ * ambiguity around how insert operations should handle the mismatch.
+ * Therefore, we should avoid states where the parent check constraint is
+ * enforced while the child is not. We actually enforced this within
+ * MergeConstraintsIntoExisting and MergeWithExistingConstraint.
+ */
+ if (currcon->coninhcount > 0 && !recursing)
+ ereport(ERROR,
+ errcode(ERRCODE_INVALID_TABLE_DEFINITION),
+ errmsg("cannot alter inherited constraint \"%s\" of
relation \"%s\" enforciability",
+ NameStr(currcon->conname),
RelationGetRelationName(rel)));
--
jian
https://www.enterprisedb.com/