Andres Freund <andres@anarazel.de> writes:
> Afaict this is a problem of a wrongly generated target list, which isn't what
> ExecInterpExprStillValid() guards against:
The targetlists are okay, really. The core problem is that each
targetlist has an instance of the MULTIEXPR_SUBLINK SubPlan with a
differently-mutated "args" list, and it looks to me like we correctly
mutated that for the associated child table. But because all the
instances share the same output Params, the ExecSetParamPlan mechanism
gets confused about which version of the SubPlan it ought to invoke
to recompute the output Params.
It occurs to me that one possible fix is to make MULTIEXPR_SUBLINK
and the associated output Params use a separate ParamExecData array;
instead of the query-wide es_param_exec_vals array, use one that
is local to the specific targetlist's ExprState. I'm not sure how
much violence that does to the current notion of an ExprState ---
do we think that is read-only during execution?
If we did have a local-to-the-expression ParamExecData array, maybe that
could be used to get a cleaner fix for things like the domain VALUES
and case-test-expression hacks.
regards, tom lane