On 2025-Mar-12, Ashutosh Bapat wrote:
> The 002_pg_upgrade test passes with and without my patches now. But
> then the tests added here do not leave behind any parent-child table.
> Previously we have found problems in dumping and restoring constraints
> in an inheritance hierarchy. I think the test should leave behind all
> the combinations of parent and child NOT NULL constraints so that
> 0002_pg_upgrade can test those.
I agree.
> Is it expected that a child may have VALID constraint but parent has
> not valid constraint?
Sure. Consider: if the parent has an unvalidated constraint, we cannot
make any assertions about the state of its children. The children may
have additional constraints of their own -- in this case, a child can
have a validated constraint even though the parent has none, or only an
unvalidatec constraint.
But the opposite is not allowed: if you know something to be true about
a parent table (to wit: that no row in it is NULL), then this must
necessarily apply to its children as well. Therefore, if there's a
valid constraint in the parent, then all children must have the same
constraint, and all such constraints must be known valid.
> Same case with partitioned table. We should leave partitioned table
> hierarchy behind for 002_pg_upgrade to test. And we need tests to test
> scenarios where a partitioned table has valid constraint but we try to
> change constraint on a partition to not valid and vice versa. I think
> we shouldn't allow such assymetry in partitioned table hierarchy and
> having a test would be better.
Agreed.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
