Re: Improving the names generated for indexes on expressions

2025-09-20 Thread Pavel Stehule
Hi út 16. 9. 2025 v 3:57 odesílatel Tom Lane napsal: > In the wake of the discussion around bug #18959 [1], here is > a modest proposal for improving the names we pick for expression > indexes. The commit message explains the details, but this > example should give the flavor: > > postgres=# cr

Improving the names generated for indexes on expressions

2025-09-17 Thread Tom Lane
In the wake of the discussion around bug #18959 [1], here is a modest proposal for improving the names we pick for expression indexes. The commit message explains the details, but this example should give the flavor: postgres=# create table mytab (f1 int, f2 text, f3 text); CREATE TABLE postgres=

Re: Improving the names generated for indexes on expressions

2025-09-16 Thread Robert Haas
On Tue, Sep 16, 2025 at 8:32 AM Tom Lane wrote: > Question is, why should we care about that? It's a fair question, and I can't think of any hard-and-fast reason. However, I suspect that some users may not like it; the quick -1 from Pavel lends credence to that theory, IMHO. People do use DDL com

Re: Improving the names generated for indexes on expressions

2025-09-16 Thread Tom Lane
"David G. Johnston" writes: > More generally, maybe map all the various common accessor operators to “.” > instead of using them directly and capture the constants when chained from > a column. That seems fairly useless. You still have a name that requires double quotes, and you can't tell one o

Re: Improving the names generated for indexes on expressions

2025-09-16 Thread David G. Johnston
On Tuesday, September 16, 2025, Robert Haas wrote: > On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston > 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 previ

Re: Improving the names generated for indexes on expressions

2025-09-16 Thread Tom Lane
"David G. Johnston" writes: > I fear consistently exceeding 63 bytes of identifier length if we choose to > display the entire expression in the name. I was worried about that too, but at least among our regression test cases, there are none that come even close to 63 bytes under this proposal.

Re: Improving the names generated for indexes on expressions

2025-09-16 Thread Tom Lane
Robert Haas writes: > On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston > 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 exp

Re: Improving the names generated for indexes on expressions

2025-09-16 Thread Robert Haas
On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston 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

Re: Improving the names generated for indexes on expressions

2025-09-15 Thread David G. Johnston
On Monday, September 15, 2025, Tom Lane wrote: > In the wake of the discussion around bug #18959 [1], here is > a modest proposal for improving the names we pick for expression > indexes. The commit message explains the details, but this > example should give the flavor: > > postgres=# create ta