Re: Improving the names generated for indexes on expressions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Improving the names generated for indexes on expressions
Date: 2026-06-04 22:31:24
Message-ID: 3533987.1780612284@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ I was hoping for opinions from more people, but so far it's crickets ]

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Is this better or worse than deparsing the whole expression to a
> string and then smushing sequences of quote-requiring characters down
> to a single underscore, as I suggested before?

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.

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.

regards, tom lane

Attachment Content-Type Size
v3-0001-Improve-the-names-generated-for-indexes-on-expres.patch text/x-diff 48.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Arne Roland 2026-06-04 22:41:20 Re: Key joins
Previous Message Maxime Schoemans 2026-06-04 22:31:07 Re: Multi-Entry Indexing for GiST & SP-GiST