Re: Inlining functions with "expensive" parameters

I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I don't quite follow the need for this. I mean, if we just stick a
>> Param reference in there and create a corresponding InitPlan, the
>> Param will be evaluated on demand, right? Is the point of the new
>> node to make sure that the Param gets re-evaluated when needed?

> Yeah. By default, an initplan is only going to be evaluated once per
> query, not once per row. It's possible that you could set up Param
> dependencies to force the correct semantics, but that would be more
> complicated, and probably less performant, than introducing a new
> expression node type. Also, I'm dubious that it could be made to work
> at all for standalone expression evaluation; Param-driven re-evaluation
> is only considered when running a plan tree.

BTW, thinking about that a bit more, standalone expressions (eg CHECK
constraints) are possibly going to need some work anyway to make this go
through. I do not think there's any mechanism in place at the moment
to set up a ParamListInfo array for such an expression. While it's
conceivable that the expression eval machinery could be set up to not
need one, I'm not real sure, if we try to make these things be
PARAM_EXEC Params.

This suggests that maybe the Params used for LambdaExprs should be a
distinct kind of Param, not the same PARAM_EXEC type that's used for
Params supplied externally to eval of a particular expression. That
would reflect the fact that expression eval handles them completely
internally.

I'm also wondering about folding CaseTestExpr and CoerceToDomainValue
into the same mechanism. It's not very hard to see those cases as
being the same as a function-based lambda.

regards, tom lane