On 2026-Feb-01, Srinath Reddy Sadipiralla wrote:
> as you have suggested i have looked whether it effects the other behaviour
> ,during table creation with not null constraints i observed that flow
> doesn't
> touch the AdjustNotNullInheritance where we added the error message,
> When running CREATE TABLE, the standard NOT NULL merging logic is
> handled by DefineRelation -> AddRelationNotNullConstraints. This function
> explicitly handles the "Constraint Selection" logic (prioritizing the
> Child's constraint if present, otherwise defaulting to the 1st
> parent's constraint), please correct me if I totally understood your
> concerns wrong here.
Okay, it should be all good then. I noticed that some of the changes in
the patch were unnecessary; I had added them transiently to cover the
inheritance case while investigating, but since the real fix only
affects directly specified constraints and doesn't touch inherited ones,
we can remove them. In particular this reverts the unpleasant change
that was going to occur for inherited constraints, which was quite bulky
in the regression tests.
I also reworded the message to be closer to our guidelines and to other
nearby messages, and expanded the code comment that described why we're
doing this check.
Here's the patch in v3, which I intend to push tomorrow morning to both
18 and master. (It backpatches cleanly). For 18 it will mean an ABI
break due to the change to AdjustNotNullInheritance()'s signature,
requiring a touch to .abi-compliance-history as well, but that comes
later.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
