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/