Re: Improving the names generated for indexes on expressions

On Thu, Jun 4, 2026 at 6:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I spent some time trying to parse out why I don't like that
> suggestion, and eventually realized that it's this: I don't want
> the behavior of CREATE INDEX to be dependent on every last detail
> of ruleutils.c. I'm afraid that that'd introduce undesirable
> cross-version changes in the names selected for indexes. Now,
> considering this sort of change at all requires an assumption that
> we can get away with breaking any applications that are sensitive
> to that. But we only have to assume that we can get away with that
> once. If we get ruleutils.c involved then I foresee a steady drip
> drip drip of edge-case naming changes, and I think that will annoy
> people.

Hmm, I don't know. I suppose you could go back and see whether making
these changes in the back-branches would produce different regression
test changes than making them against the master branch.

> In any event, the cfbot has been nagging me that this patch needs
> a rebase, so here's v3. The only change from v2 is that there are
> some new test cases in indexing.sql that need adjustment.

...but whether you do that research or not, I still think this is a
very significant improvement. For those not wanting to open up the
patch:

- An index on ((a + 0)) now gets the name idxpart1_a_0_idx instead of
idxpart1_expr_idx.
- An index on ((a + b)) now gets the name idxpart_a_b_idx instead of
idxpart_expr_idx.
- An index on (abs(b)) now gets the name idxpart1_abs_b_idx instead of
idxpart1_abs_idx.

Personal taste certainly enters into the calculus here, but IMHO
calling everything BLAH_expr_idx because the topmost thing is some
kind of operator invocation is a really poor user experience, and even
for cases where the top-level thing is a function invocation,
including more than just the name of the top-level function in the
index name seems like a really significant improvement.

I think it would be good to press ahead with this. Admittedly, you
have gotten feedback from a limited number of people, but if you
commit this soon-ish, there will be lots of time to hear from people
who dislike it before we run out of time to rethink for v20. If the
consensus is that we revert it or change the algorithm, so be it, but
it doesn't seem like you will learn much more about what people think
without committing something.

--
Robert Haas
EDB: http://www.enterprisedb.com