Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/6059~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/6059
Choose a head ref
  • 2 commits
  • 16 files changed
  • 2 contributors

Commits on Dec 25, 2025

  1. Improve the names generated for indexes on expressions. 

    If the user doesn't specify a name for an index, it's generated
based on the names chosen for the index columns (which the user
has no control over).  For index columns that are just columns
of the base relation, the index column name is the same as the
base column name; but for index columns that are expressions,
it's less clear what to do.  Up to now, what we have done is
equivalent to the heuristics used to choose SELECT output
column names, except that we fall back to "expr" not "?column?"
in the numerous cases that FigureColname doesn't know what
to do with.  This frequently leads to collisions of generated
index names, which we can handle but only at the cost of
user confusion; also there's some risk of concurrent index
creations trying to use the same name.  Let's try to do better.

Messing with the FigureColname heuristics would have a very
large blast radius, since that affects the column headings
that applications see.  That doesn't seem wise, but fortunately
SQL queries are seldom directly concerned with index names.
So we should be able to change the index-name generation rules
as long as we decouple them from FigureColname.

The rule proposed in this patch is to dig through the expression,
extract the names of Vars, the string representations of Consts,
and the names of functions, and run those together with underscores
between.  Other expression node types are ignored but descended
through.  We could work harder by handling more node types, but
it seems like this is likely to be sufficient to arrive at unique
index names in many cases.

Unlike the previous iteration of this patch, I didn't include
operator names in generated index names.  I'm not convinced that's
better, but some other people are awfully resistant to the idea
of having to double-quote index names (despite the existence of
many cases where you'd have to anyway).

I've also chosen to strip Const representations down to only
alphanumeric characters (plus non-ASCII characters, which our
parser treats as alphabetic anyway).  So for example "x + 1.0"
would be represented as "x_10".  This likewise avoids possible
quoting problems.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/18959-f63b53b864bb1417@postgresql.org
    @tglsfdc
    tglsfdc authored and Commitfest Bot committed Dec 25, 2025
    Configuration menu
    Copy the full SHA
    d07ccc8 View commit details
    Browse the repository at this point in the history

  2. [CF 6059] v2 - Improving the names generated for indexes on expressions 

    This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/6059

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/238409.1762036106@sss.pgh.pa.us
Author(s): Tom Lane
    Commitfest Bot committed Dec 25, 2025
    Configuration menu
    Copy the full SHA
    1b619f1 View commit details
    Browse the repository at this point in the history
Loading