Hi Tom,
On Thu, Jun 19, 2025 at 12:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > This seems very closely related to commit 3db61db48 [1], which fixed
> > a similar behavior for child foreign key constraints. Per that commit
> > message, it's a good idea for the child objects to have names related
> > to the parent objects, so we ought to change this behavior regardless
> > of any concurrent-failure considerations.
>
> I experimented with the attached, which borrows a couple of ideas
> from 3db61db48 to produce names like "parent_index_2" when cloning
> indexes. While it should help with the immediate problem, I'm not
> sure if this is acceptable, because there are a *lot* of ensuing
> changes in the regression tests, many more than 3db61db48 caused.
> (Note that I didn't bother to fix places where the tests rely on
> a generated name that has changed; the delta in the test outputs
> is merely meant to give an idea of how much churn there is.
> I didn't check non-core test suites, either.)
I think this approach is better because each child index inherits its
parent's index name with an extra number, creating a more
intuitive hierarchy. This naming convention makes it easier to
understand the partition levels directly from the index name.
So I'm +1 for this idea.
>
> Also, looking at the error message changes, I'm less sure that
> this is a UX improvement than I was about 3db61db48. Do people
> care which partition a uniqueness constraint failed in? In
> the current behavior, the index name will reflect that, but
> with this behavior, not so much.
I can see the benefit of being able to identify the associated
partition directly by checking the index name. Can we prepend
the partition rel name to the index name, this will make the
index longer, not sure if it's acceptable.
>
> Anyway, maybe this is a good idea or maybe it isn't. Thoughts?
>
> regards, tom lane
>
--
Regards
Junwang Zhao
