Re: Fix bug of CHECK constraint enforceability recursion - Mailing list pgsql-hackers

From Chao Li
Subject Re: Fix bug of CHECK constraint enforceability recursion
Date
Msg-id FD1A15D5-0FAD-4CD3-9D5C-C76F0D813563@gmail.com
Whole thread
In response to Re: Fix bug of CHECK constraint enforceability recursion  (jian he <jian.universality@gmail.com>)
List pgsql-hackers

> On Jun 17, 2026, at 11:27, jian he <jian.universality@gmail.com> wrote:
>
> On Tue, Jun 9, 2026 at 8:32 AM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>> In v10, I split the “because” part to a errdetail, also moved out NOT ENFORCED out of the translate message.
>>
>
> ATCheckCheckConstrHasEnforcedParent
> ``````
>            if (constraints_equivalent(parenttup, contuple,
>                                       RelationGetDescr(conrel)))
>            {
> ``````
> The above IF condition is basically always true (see
> MergeConstraintsIntoExisting), unless an inherited check constraint
> has a
> different definition, which should not happen.
> So I did a quick refactor here, which also drops the nesting level down by one.
>
> Other than that, v10 looks good to me.
>
>
>
> --
> jian
> https://www.enterprisedb.com/
> <v10-0001-misc-refactor-ATCheckCheckConstrHasEnforcedParent.nocfbot>

Thanks for your suggestion, I think that is correct.

PFA v11 - 0001 integrated Jian’s change; 0002 and 0003 unchanged.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/





Attachment

pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
Next
From: Amit Kapila
Date:
Subject: Re: DOCS - Clarify behaviour when EXCEPT tables are moved/renamed