diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2023-02-17 16:40:34 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2023-02-17 16:40:34 -0500 |
commit | 3dd287c14facd5ee17e386175752a75ce16a1daa (patch) | |
tree | 217add1a0d3a6f3fc1bdadc180338f0b886a5b8b /src/backend/executor/spi.c | |
parent | a40e7b75e689c3f7f9c9c77106a1ff59fa61d938 (diff) | |
download | postgresql-3dd287c14facd5ee17e386175752a75ce16a1daa.tar.gz postgresql-3dd287c14facd5ee17e386175752a75ce16a1daa.zip |
Print the correct aliases for DML target tables in ruleutils.
ruleutils.c blindly printed the user-given alias (or nothing if there
hadn't been one) for the target table of INSERT/UPDATE/DELETE queries.
That works a large percentage of the time, but not always: for queries
appearing in WITH, it's possible that we chose a different alias to
avoid conflict with outer-scope names. Since the chosen alias would
be used in any Var references to the target table, this'd lead to an
inconsistent printout with consequences such as dump/restore failures.
The correct logic for printing (or not) a relation alias was embedded
in get_from_clause_item. Factor it out to a separate function so that
we don't need a jointree node to use it. (Only a limited part of that
function can be reached from these new call sites, but this seems like
the cleanest non-duplicative factorization.)
In passing, I got rid of a redundant "\d+ rules_src" step in rules.sql.
Initial report from Jonathan Katz; thanks to Vignesh C for analysis.
This has been broken for a long time, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/e947fa21-24b2-f922-375a-d4f763ef3e4b@postgresql.org
Discussion: https://postgr.es/m/CALDaNm1MMntjmT_NJGp-Z=xbF02qHGAyuSHfYHias3TqQbPF2w@mail.gmail.com
Diffstat (limited to 'src/backend/executor/spi.c')
0 files changed, 0 insertions, 0 deletions