> On Jun 14, 2026, at 23:52, Fujii Masao <[email protected]> wrote: > > On Fri, Jun 12, 2026 at 11:02 PM Chao Li <[email protected]> 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/
v3-0001-Fix-ALTER-DOMAIN-VALIDATE-CONSTRAINT-locking.patch
Description: Binary data
