MIME-Version: 1.0
References: 
 <CALHMmB_q1Sme-7_OvGiZAyJ6eSB8eKkfRuwreZK3rO88Nfk78w@mail.gmail.com>
In-Reply-To: 
 <CALHMmB_q1Sme-7_OvGiZAyJ6eSB8eKkfRuwreZK3rO88Nfk78w@mail.gmail.com>
From: Vismay Tiwari <vismay.t@gmail.com>
Date: Thu, 9 Jul 2026 15:01:43 +0530
Message-ID: 
 <CALHMmB-wB_=ZtCB+MVjrELZ8vdujMop82hpyX4UjHKx1LMHnfA@mail.gmail.com>
Subject: Re: BUG #19507: Auto-named partition table constraint conflicts
To: pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALHMmB-wB_%3DZtCB%2BMVjrELZ8vdujMop82hpyX4UjHKx1LMHnfA%40mail.gmail.com>
Precedence: bulk

Hi Marko,

Apologies for the noise =E2=80=94 I replied off the original report and onl=
y
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=E2=80=AFPM Vismay Tiwari <vismay.t@gmail.com> w=
rote:
>
> Hi,
>
> Thanks for the report, Marko. I could reproduce both cases on current mas=
ter.
>
> The root of it is that when the constraint name is auto-generated for the
> partitioned parent, ChooseConstraintName only checks for a clash within t=
he
> parent's own schema. So a partition sitting in another schema that alread=
y 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 deliberatel=
y kept
> those names out of the checknames/nnnames lists, since those also drive t=
he
> duplicate check for explicitly-named constraints, and folding them in wou=
ld
> 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 NU=
LL 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