Use JOIN USING aliases in ruleutils.c
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.
Attachments:
0001-Use-JOIN-USING-aliases-in-ruleutils.c.patchtext/plain; charset=UTF-8; name=0001-Use-JOIN-USING-aliases-in-ruleutils.c.patchDownload+169-122
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.