Print the correct aliases for DML target tables in ruleutils.
Tom Lane <tgl@sss.pgh.pa.us>
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
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/utils/adt/ruleutils.c | modified | +84 −61 |
| src/test/regress/expected/rules.out | modified | +30 −17 |
| src/test/regress/sql/rules.sql | modified | +12 −1 |
Discussion
- Support logical replication of DDLs 467 messages · 2022-02-21 → 2026-06-11
- The output sql generated by pg_dump for a create function refers to a modified table name 8 messages · 2023-02-17