Hi, On 2023-03-02 14:33:35 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Around > > https://www.postgresql.org/message-id/20230224015417.75yimxbksejpffh3%40awork3.anarazel.de > > I suggested that we should evaluate the arguments of correlated SubPlans as > > part of the expression referencing the subplan. > > > Here's a patch for that. > > I looked through this, and there is one point that is making me really > uncomfortable. This bit is assuming that we can bind the address of > the es_param_exec_vals array right into the compiled expression: > > + ParamExecData *prm = &estate->es_param_exec_vals[paramid]; > + > + ExecInitExprRec(lfirst(pvar), state, &prm->value, &prm->isnull); > > Even if that works today, it'd kill the ability to use the compiled > expression across more than one executor instance, which seems like > a pretty high price. Also, I think it probably fails already in > EvalPlanQual contexts, because EvalPlanQualStart allocates a separate > es_param_exec_vals array for EPQ execution.
Yea, I wasn't super comfortable with that either. I concluded it's ok because we already cache pointers to the array inside each ExprContext. > I think we'd be better off inventing an EEOP_SET_PARAM_EXEC step type > that is essentially the inverse of EEOP_PARAM_EXEC/ExecEvalParamExec, > and then evaluating each parameter value into the expression's > scratch Datum/isnull fields and emitting SET_PARAM_EXEC to copy those > to the correct ParamExecData slot. Agreed, that'd make sense. If we can build the infrastructure to figure out what param to use, that'd also provide a nice basis for using params for CaseTest etc. Greetings, Andres Freund