Re: Improving the names generated for indexes on expressions
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
"pgsql-hackers@lists.postgresql.org"
<pgsql-hackers@lists.postgresql.org>
Date: 2025-09-16T12:32:17Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston > <david.g.johnston@gmail.com> wrote: >> If there are no function names present, output “expr” in lieu of a function name. Then just output any columns that are present. No operators, no constants. > In the previous discussion, the user's expression indexes were on > these expressions: > jsondata -> 'a' -> 'b' > jsondata -> 'x' -> 'y' > So "no operators, no constants" wouldn't really allow us to make any > useful progress, inasmuch as it would throw away everything that > matters. Precisely. It's exactly expression indexes on OpExprs that FigureColumn is completely useless for; if we don't do something for those then we've not moved the needle much. I initially tried leaving out Consts, but that didn't work well on the indexes in the regression tests, let alone the field example Robert cites. One thing I was thinking about after putting up the initial draft was to suppress the underscores around operator names, so that instead of mytab_jsondata_->_a_->_b_idx the above would net you mytab_jsondata->a->b_idx It's less consistent but looks less busy too. > I am not really sure we want to do what Tom proposes here because, as > Pavel says, it would result in a lot of indexes containing special > characters in the name. Question is, why should we care about that? regards, tom lane
Commits
-
Improve the names generated for indexes on expressions.
- 181b6185c79e master landed