Use JOIN USING aliases in ruleutils.c
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t45463psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 03:21 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t45463_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t45463_1 && git checkout t45463_1Patchset v1 (message #1) is on t45463_1
When reverse-compiling a query, ruleutils.c has some complicated code to
handle the join output columns of a JOIN USING join. There used to be
no way to qualify those columns, and so if there was a naming conflict
anywhere in the query, those output columns had to be renamed to be
unique throughout the query.
Since PostgreSQL 14, we have a new feature that allows adding an alias
to a JOIN USING clause. This provides a better solution to this
problem. This patch changes the logic in ruleutils.c so that if naming
conflicts with JOIN USING output columns are found in the query, these
JOIN USING aliases with generated names are attached everywhere and the
columns are then qualified everywhere.
The test output changes show the effects nicely.
Obviously, the copy-and-paste code in set_rtable_names() could be
refactored a bit better, perhaps. I also just named the generated
aliases "ju" with numbers added, maybe there are other ideas for how to
generate these names.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
When reverse-compiling a query, ruleutils.c has some complicated code to
handle the join output columns of a JOIN USING join. There used to be
no way to qualify those columns, and so if there was a naming conflict
anywhere in the query, those output columns had to be renamed to be
unique throughout the query.
Since PostgreSQL 14, we have a new feature that allows adding an alias
to a JOIN USING clause. This provides a better solution to this
problem.
I looked this over briefly, and came away fairly dissatisfied.
My big fear is that it will reduce portability of pg_dump output:
views that would have loaded successfully into pre-v14 servers
no longer will, and your chances of porting them to other RDBMSes
probably go down too. Once v13 becomes EOL, that will be less of a
concern, but I think it's a valid objection for awhile yet.
Also, it doesn't seem like we're getting much in return for the
portability hazard. AFAICS the patch actually makes a net addition
of code to ruleutils.c, which perhaps means that you've not worked
hard enough on removing no-longer-needed code. Maybe there's an
argument that the new output is more readable, but these regression
test changes don't look like any huge step forward to me.
I also just named the generated
aliases "ju" with numbers added, maybe there are other ideas for how to
generate these names.
For my taste, names like "join_N" would be better.
On the whole, I'd recommend putting this idea on the back burner
for three or four years more.
regards, tom lane
On 23.03.22 16:14, Tom Lane wrote:
My big fear is that it will reduce portability of pg_dump output:
views that would have loaded successfully into pre-v14 servers
no longer will, and your chances of porting them to other RDBMSes
probably go down too. Once v13 becomes EOL, that will be less of a
concern, but I think it's a valid objection for awhile yet.
That's a good point. I'll withdraw the patch for now.