From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Evaluate arguments of correlated SubPlans in the referencing ExprState |
Date: | 2023-03-02 20:05:49 |
Message-ID: | 20230302200549.l2ikytmnqzvy5a7a@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-03-02 14:33:35 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-02 20:10:31 | Re: Evaluate arguments of correlated SubPlans in the referencing ExprState |
Previous Message | Jacob Champion | 2023-03-02 20:04:34 | Re: Auth extensions, with an LDAP/SCRAM example [was: Proposal: Support custom authentication methods using hooks] |