Re: Evaluate arguments of correlated SubPlans in the referencing ExprState
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Date: 2023-03-02T19:33:35Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Evaluate arguments of correlated SubPlans in the referencing ExprState
- a7f107df2b70 18.0 landed
-
Doc: improve documentation for jsonpath behavior.
- 7014c9a4bba2 17.0 cited
Andres Freund <andres@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. 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. regards, tom lane