Re: BUG #19507: Auto-named partition table constraint conflicts

Hi Marko,

Apologies for the noise — I replied off the original report and only
afterward noticed you'd already posted a complete patch back on the 4th.
Please disregard the patch I sent; yours is clearly further along
(backpatch-tested and already in review).

Happy to review or test it if a second pair of eyes would help. Sorry for
the overlap.

Regards,
Vismay

On Thu, Jul 9, 2026 at 2:45 PM Vismay Tiwari <vismay(dot)t(at)gmail(dot)com> wrote:
>
> 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