Set hasSubLinks when expanding a whole-row join alias reference If a subquery has been flattened into its parent, the joinaliasvars entries of a join above it can be arbitrary expressions rather than plain Vars, so expanding a reference to such a join alias may insert a SubLink into a lower-level subquery. flatten_join_alias_vars_mutator detects that and sets the subquery's hasSubLinks flag, but only in the single-column code path; the whole-row path just asserted in a comment that its recursive call would handle this, which is true only when the alias entry is itself a Var referencing another join.
Hence a whole-row reference to such a join appearing in a sub-select left that sub-select's hasSubLinks false, so preprocess_expression skipped SS_process_sublinks for it, and the unprocessed SubLink reached code that is not prepared for one: this produced "cannot handle unplanned sub-select" from cost_qual_eval, an assertion failure in preprocess_aggrefs, or "unrecognized node type" at execution, depending on where in the sub-select the SubLink ended up. To fix, make the same check in the whole-row expansion path. Back-patch to all supported branches. Author: Richard Guo <[email protected]> Reviewed-by: Ayush Tiwari <[email protected]> Discussion: https://postgr.es/m/cambws49pgenfhqtz2gszwatf0_lxyegmpgt++jsfxun7nzu...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6c0698339e3d792f679fc39866fb7d3ebeb3fe09 Modified Files -------------- src/backend/optimizer/util/var.c | 6 +++++- src/test/regress/expected/subselect.out | 25 +++++++++++++++++++++++++ src/test/regress/sql/subselect.sql | 12 ++++++++++++ 3 files changed, 42 insertions(+), 1 deletion(-)
