Fix two issues in deparsing. If the target relation of UPDATE, DELETE, or MERGE has an alias, we printed that "bare" (without AS or forced quoting), the same as we do in FROM. However, if that alias is "set", there's an ambiguity with the SET keyword that must follow the relation specification. The parser would choose the wrong interpretation, so that the dumped query would fail to reload. The least surprising and most future-proof fix seems to be to always print AS in these contexts, as we already did in INSERT.
Also, we were insufficiently careful about parenthesizing the left-hand argument of a SubLink (IN, op ANY/ALL, or row comparison), so that the printed expression might not parse back with the intended meaning depending on operator precedence. This is only a problem in "pretty-print" mode, since non-pretty mode fully parenthesizes every operator. So it isn't a hazard for pg_dump, but it still seems like something to fix. To do so, switch to using get_rule_expr_paren. Presently that will add parens in some cases where it wouldn't really be necessary, but that's better than the reverse, and it arguably is helpful for readability anyway. Author: Henson Choi <[email protected]> Reviewed-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/caaae_zdqxin5neb5atrcbzqudcmoeyxrqhan+tvp0f30ocu...@mail.gmail.com Discussion: https://postgr.es/m/CAAAe_zCy+D45Qd_br484F+V34y0BVA=hp_7cb=u6hysymke...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0da632e084842c36ec31d87adfc401b54ed7d7b2 Modified Files -------------- src/backend/utils/adt/ruleutils.c | 25 ++++++++++++++++++------- src/test/regress/expected/create_view.out | 10 ++++++++-- src/test/regress/expected/returning.out | 6 +++--- src/test/regress/expected/rules.out | 12 ++++++------ src/test/regress/sql/create_view.sql | 5 ++++- 5 files changed, 39 insertions(+), 19 deletions(-)
