Re: Use JOIN USING aliases in ruleutils.c
От | Tom Lane |
---|---|
Тема | Re: Use JOIN USING aliases in ruleutils.c |
Дата | |
Msg-id | 2719157.1648048463@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Use JOIN USING aliases in ruleutils.c (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: Use JOIN USING aliases in ruleutils.c
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: