Re: Improving the names generated for indexes on expressions
От | Tom Lane |
---|---|
Тема | Re: Improving the names generated for indexes on expressions |
Дата | |
Msg-id | 944930.1758025937@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Improving the names generated for indexes on expressions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Improving the names generated for indexes on expressions
|
Список | 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 arepresent. 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
В списке pgsql-hackers по дате отправления: