Hi,
Thanks for the report, Marko. I could reproduce both cases on current master.
The root of it is that when the constraint name is auto-generated for the
partitioned parent, ChooseConstraintName only checks for a clash within the
parent's own schema. So a partition sitting in another schema that already has
a constraint by that name isn't noticed, and the name then collides once it's
propagated down. A same-schema partition doesn't trip this, because the
namespace-scoped lookup already sees that one and picks a non-conflicting name;
that makes it specific to partitions in other schemas.
The attached patch gathers the constraint names already present on the
descendants and passes them to ChooseConstraintName as names to avoid, so the
generated name comes out unique across the whole hierarchy. I deliberately kept
those names out of the checknames/nnnames lists, since those also drive the
duplicate check for explicitly-named constraints, and folding them in would
break legitimate merges of same-named inherited constraints. It's guarded on
relhassubclass, so there's no extra work for tables without children.
I added a regression test in constraints.sql covering both the SET NOT NULL and
ADD CHECK cases; make check passes.
One thing I didn't chase down: foreign-key names go through a similar
auto-naming path, so they may have the same issue. I haven't tested that, so
I'm flagging it in case it's worth a look.
Regards,
Vismay Tiwari
