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:t45266psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 03:51 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 t45266_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 t45266_1 && git checkout t45266_1Patchset v1 (message #1) is on t45266_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.
I made it so that new JOIN USING aliases are only created if needed in
the query, since we already have the logic of has_dangerous_join_using()
to compute when that is needed. We could probably do away with that too
and always use them, but I think that would be surprising and not what
people want.
The regression test changes illustrate the effects very well.
This is PoC-level right now. You will find blatant code duplication in
set_rtable_names(), and for now I have only commented out some code that
could be removed, not actually removed it.