Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit43f2e76

Browse files
committed
Fix mis-deparsing of ORDER BY lists when there is a name conflict.
If an ORDER BY item in SELECT is a bare identifier, the parserfirst seeks it as an output column name of the SELECT (for SQL92compatibility). However, ruleutils.c is expecting the SQL99interpretation where such a name is an input column name. So it'spossible to produce an incorrect display of a view in the (admittedlypretty ill-advised) case where some other column is renamed in theSELECT output list to match an ORDER BY column.This can be fixed by table-qualifying such names in the dumpedview text. To avoid cluttering less-ill-advised queries, we'dlike to do so only when there's an actual name conflict.That requires passing the current get_query_def call's resultDescparameter down to get_variable, so that it can determine whatthe output column names are. In hopes of reducing rather thanincreasing notational clutter in ruleutils.c, I moved that valueinto the deparse_context struct and removed it from the parameterlists of get_query_def's other subroutines.I made a few other cosmetic changes while at it:* Likewise move the colNamesVisible parameter into deparse_context.* Rename deparse_context's windowTList field to targetList,since it's no longer used only in connection with WINDOW clauses.* Replace the special_exprkind field with a bool inGroupBy,since that was all it was being used for, and the apparentflexibility of storing a ParseExprKind proved to be illusory.(We need a separate varInOrderBy field to make this patch work.)* Remove useless save/restore logic in get_select_query_def.In principle, this bug is quite old. However, it seems unreachablebefore1b4d280, because before that the presence of "new" and "old"entries in a view's rangetable caused us to always table-qualify everyVar reference in dumped views. Hence, back-patch to v16 where thatcame in.Per bug #18589 from Quynh Tran.Discussion:https://postgr.es/m/18589-70091cb81db1a3f1@postgresql.org
1 parentedee0c6 commit43f2e76

File tree

3 files changed

+217
-100
lines changed

3 files changed

+217
-100
lines changed

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp