Re: Fix ALTER DOMAIN VALIDATE CONSTRAINT locking

> On Jun 14, 2026, at 23:52, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Fri, Jun 12, 2026 at 11:02 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> From a runtime behavior perspective, yes, this patch reverts the behavior change made by 16a0039dc0d1.
>
> Yes.
>
>
>> However:
>>
>> * 16a0039dc0d1 also refactored validateDomainCheckConstraint() to allow passing in the lock mode, and I think that refactoring is still useful and maybe worth keeping.
>
> I'd prefer to remove that refactoring code, since after the fix there
> is no longer any user of the lockmode argument in
> validateDomainCheckConstraint().
>
>
>> * A follow-up commit, a99c6b56f, made validating an already-validated constraint a no-op. A direct revert of 16a0039dc0d1 would conflict with later changes around this code.
>
> Yes, but fixing that conflict does not seem very difficult, no?
>
>
>> * This patch also adds a test to prevent future changes from making the same mistake.
>
> +1 for adding the test!
>
>
>>> If we make this change, then the release note item should be removed
>>> entirely, ISTM.
>>>
>>
>> True. Once this patch is pushed, this item should be removed from the release note.
>
> Agreed.
>
> Regards,
>
> --
> Fujii Masao

Okay, I manually reverted 16a0039dc0d1 with retaining a99c6b56f. I also updated the commit message accordingly. See the attached v3.

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