Fix placement of initPlans when forcibly materializing a subplan.
If we forcibly place a Material node atop a finished subplan, we need
to move any initPlans attached to the subplan up to the Material node,
in order to keep SS_finalize_plan() happy. I'd figured this out in
commit 7b67a0a49 for the case of materializing a cursor plan, but out of
an abundance of caution, I put the initPlan movement hack at the call
site for that case, rather than inside materialize_finished_plan().
That was the wrong thing, because it turns out to also be necessary for
the only other caller of materialize_finished_plan(), ie subselect.c.
We lacked any test cases that exposed the mistake, but bug#14524 from
Wei Congrui shows that it's possible to get an initPlan reference into
the top tlist in that case too, and then SS_finalize_plan() complains.
Hence, move the hack into materialize_finished_plan().
In HEAD, also relocate some recently-added tests in subselect.sql, which
I'd unthinkingly dropped into the middle of a sequence of related tests.
Report: https://postgr.es/m/20170202060020.1400.89021@wrigleys.postgresql.org
Branch
------
REL9_6_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/b971a98cea988e03054077db613fc893564f7bf7
Modified Files
--------------
src/backend/optimizer/plan/createplan.c | 10 ++++++++++
src/backend/optimizer/plan/planner.c | 16 +---------------
src/test/regress/expected/subselect.out | 23 +++++++++++++++++++++++
src/test/regress/sql/subselect.sql | 5 +++++
4 files changed, 39 insertions(+), 15 deletions(-)