Fix interaction of CASE and ArrayCoerceExpr.
An array-type coercion appearing within a CASE that has a constant
(after const-folding) test expression was mangled by the planner, causing
all the elements of the resulting array to be equal to the coerced value
of the CASE's test expression. This is my oversight in commit c12d570fa:
that changed ArrayCoerceExpr to use a subexpression involving a
CaseTestExpr, and I didn't notice that eval_const_expressions needed an
adjustment to keep from folding such a CaseTestExpr to a constant when
it's inside a suitable CASE.
This is another in what's getting to be a depressingly long line of bugs
associated with misidentification of the referent of a CaseTestExpr.
We're overdue to redesign that mechanism; but any such fix is unlikely
to be back-patchable into v11. As a stopgap, fix eval_const_expressions
to do what it must here. Also add a bunch of comments pointing out the
restrictions and assumptions that are needed to make this work at all.
Also fix a related oversight: contain_context_dependent_node() was not
aware of the relationship of ArrayCoerceExpr to CaseTestExpr. That was
somewhat fail-soft, in that the outcome of a wrong answer would be to
prevent optimizations that could have been made, but let's fix it while
we're at it.
Per bug #15471 from Matt Williams. Back-patch to v11 where the faulty
logic came in.
Discussion: https://postgr.es/m/15471-1117f49271989bad@postgresql.org
Branch
------
REL_11_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/2bd6dcdeff09f6c3853d847b7516c9d51646716d
Modified Files
--------------
src/backend/executor/execExpr.c | 9 +++---
src/backend/optimizer/util/clauses.c | 57 +++++++++++++++++++++++++++++++-----
src/backend/parser/parse_coerce.c | 7 ++++-
src/backend/parser/parse_target.c | 8 ++++-
src/include/nodes/primnodes.h | 16 ++++++++--
src/test/regress/expected/case.out | 14 +++++++++
src/test/regress/sql/case.sql | 13 ++++++++
7 files changed, 108 insertions(+), 16 deletions(-)