Fix EXPLAIN of dummy set operations some more. EXPLAIN failed to deal with varno-0 Vars that are made by prepunion.c and can survive into a finished plan in the case where a provably empty set operation is replaced by a dummy Result (which is possible since 03d40e4b5). Commit 928df067d tried to fix this, but it was a couple bricks shy of a load. First, it only dealt with varno-0 Vars at the top level of the Result's tlist, but they could be buried under coercion expressions. Fix that by doing a recursive mutation. Second, it always replaced varno 0 with varno 1, but that's just wrong: the Result might represent a group of setop leaf queries that do not include the leftmost leaf. That led to displaying the wrong variable(s) as outputs of the Result, risking confusion. Fortunately, we can get the actual child relids from the recently-added Result.relids field, and use that to discover the leftmost child represented by the Result.
This was found while discussing bug #19742, but it's really an independent issue. Author: shihao zhong <[email protected]> Co-authored-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/CAGRkXqTFwygKmjLG_Y=kbXRHsePFmD6k+qrzVLP4_KrG+-=o...@mail.gmail.com Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/90893c7b7cf355b87f403a8a56293abe33ad7848 Modified Files -------------- src/backend/optimizer/plan/setrefs.c | 69 ++++++++++++++++++++++++++---------- src/test/regress/expected/union.out | 20 +++++++++++ src/test/regress/sql/union.sql | 9 +++++ 3 files changed, 79 insertions(+), 19 deletions(-)
