| 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 |
| 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 |