On Wed, Jun 18, 2025 at 10:16 PM 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.)
>
> 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.
>
> Anyway, maybe this is a good idea or maybe it isn't. Thoughts?
I haven't reviewed the patch itself, but I like the idea. We're now
consistently using the parent index name for partitioned indexes,
whether they're named or unnamed indexes. That looks like a great
improvement. And I think including the partition number of each level
in the index name significantly enhances its clarity, especially
within a multi-level partition hierarchy.
--
Regards,
Dilip Kumar
Google
