Re: Use JOIN USING aliases in ruleutils.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use JOIN USING aliases in ruleutils.c
Date: 2022-03-23 15:14:23
Message-ID: 2719157.1648048463@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-03-23 15:19:26 Re: New Object Access Type hooks
Previous Message Andres Freund 2022-03-23 14:58:18 Re: pgsql: Unbreak the build.