Fix planner error (or assert trap) with nested set operations.
As reported by Sean Johnston in bug #14614, since 9.6 the planner can fail
due to trying to look up the referent of a Var with varno 0. This happens
because we generate such Vars in generate_append_tlist, for lack of any
better way to describe the output of a SetOp node. In typical situations
nothing really cares about that, but given nested set-operation queries
we will call estimate_num_groups on the output of the subquery, and that
wants to know what a Var actually refers to. That logic used to look at
subquery->targetList, but in commit 3fc6e2d7f I'd switched it to look at
subroot->processed_tlist, ie the actual output of the subquery plan not the
parser's idea of the result. It seemed like a good idea at the time :-(.
As a band-aid fix, change it back.
Really we ought to have an honest way of naming the outputs of SetOp steps,
which suggests that it'd be a good idea for the parser to emit an RTE
corresponding to each one. But that's a task for another day, and it
certainly wouldn't yield a back-patchable fix.
Report: https://postgr.es/m/20170407115808.25934.51866@wrigleys.postgresql.org
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/89deca582a345b9c423bed8ebcf24b6ee81a9953
Modified Files
--------------
src/backend/optimizer/prep/prepunion.c | 12 +++++++++++-
src/test/regress/expected/union.out | 25 +++++++++++++++++++++++++
src/test/regress/sql/union.sql | 6 ++++++
3 files changed, 42 insertions(+), 1 deletion(-)