Fix constraint validation when merging with a NOT ENFORCED constraint

[NikolayS]

Summary

Fixes a correctness bug where ALTER TABLE child ADD CONSTRAINT on a legacy-inheritance child could mark an inherited NOT ENFORCED CHECK constraint as both enforced and validated without scanning existing rows, leaving trusted-but-false catalog metadata. With constraint_exclusion = on, the planner then trusted the false constraint and silently returned wrong query results (rows filtered out that actually exist in the table).

Root cause

MergeWithExistingConstraint() in src/backend/catalog/heap.c, when merging a local ENFORCED constraint into an existing inherited NOT ENFORCED one, unconditionally set:

con->conenforced = true;
con->convalidated = true;

No Phase 3 verification scan was ever queued, so rows violating the constraint survived while pg_constraint claimed the constraint was validated.

Fix

Two coordinated changes:

1. src/backend/catalog/heap.c — MergeWithExistingConstraint() now sets convalidated from the new constraint's initially_valid flag instead of unconditionally to true. A merge with a NOT VALID constraint now also correctly leaves the constraint NOT VALID (previously the not-valid state was silently ignored), to be validated later with ALTER TABLE ... VALIDATE CONSTRAINT.

2. src/backend/commands/tablecmds.c — ATAddCheckNNConstraint() records, before calling AddRelationNewConstraints(), whether an identically-named NOT ENFORCED check constraint exists that the merge would promote to enforced. If the merge happens and the new constraint is initially valid, it queues a Phase 3 verification scan of the existing rows — mirroring what ALTER TABLE ... ALTER CONSTRAINT ... ENFORCED does. If existing rows violate the constraint, the ALTER now fails with check constraint ... is violated by some row and the catalog change rolls back.

Behavior after the fix

• ALTER TABLE child ADD CONSTRAINT iso CHECK (tenant = 1) over an inherited NOT ENFORCED constraint with violating rows → error, catalog unchanged, query results stay correct.
• Same command with compliant rows → merge succeeds, constraint enforced and validated (rows were actually verified).
• ... NOT VALID variant → merge succeeds without a scan; constraint becomes enforced but stays NOT VALID; VALIDATE CONSTRAINT then behaves as expected.
• ALTER COLUMN ... TYPE re-add path re-verifies rows through the same mechanism.

Testing

• New regression tests in src/test/regress/sql/inherit.sql covering the violating-row error, the NOT VALID merge state, and the successful verified merge; expected output updated (including the pre-existing inh_check_constraint10 case, whose NOT VALID state is now preserved instead of ignored).
• Full core regression suite passes: All 245 tests passed (make check, assert-enabled build).
• Original repro from the bug report verified fixed manually.

A mailing-list-ready format-patch of this commit is available for posting to pgsql-hackers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WKfageiP8Th6TgzZuyCpfQ

---

Generated by Claude Code