On Tue, Jun 16, 2026 at 9:44 PM Robert Haas <[email protected]> wrote: > > On Thu, Jun 4, 2026 at 6:31 PM Tom Lane <[email protected]> wrote: > > 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. > > Hmm, I don't know. I suppose you could go back and see whether making > these changes in the back-branches would produce different regression > test changes than making them against the master branch. > > > 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. > > ...but whether you do that research or not, I still think this is a > very significant improvement. For those not wanting to open up the > patch: > > - An index on ((a + 0)) now gets the name idxpart1_a_0_idx instead of > idxpart1_expr_idx. > - An index on ((a + b)) now gets the name idxpart_a_b_idx instead of > idxpart_expr_idx. > - An index on (abs(b)) now gets the name idxpart1_abs_b_idx instead of > idxpart1_abs_idx. > > Personal taste certainly enters into the calculus here, but IMHO > calling everything BLAH_expr_idx because the topmost thing is some > kind of operator invocation is a really poor user experience, and even > for cases where the top-level thing is a function invocation, > including more than just the name of the top-level function in the > index name seems like a really significant improvement. >
+1. I haven't followed this thread but the examples along with your explanation for the same clearly sounds like an improvement to me. -- With Regards, Amit Kapila.
