Re: Inlining functions with "expensive" parameters

Hi,

On 2017-11-16 15:27:59 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On November 16, 2017 11:44:52 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Yeah, there's no mechanism like that now, but there could be.
>
> > Right, but it doesn't sound that hard to introduce. Basically there'd need to be a WithParamValue node, that first evaluates parameters and then executes the child expression. I'm thinking of doing this hierarchically so there's less issues with the setting of the param value being moved away from the child expression using it.
>
> Yeah. If you also gave it the ability to optionally enforce strictness
> (ie, skip child expr and return NULL if any param is NULL) then we could
> do away with all of the parameter-based restrictions on inlining, since
> the semantics of parameter eval wouldn't change by inlining.

Yep. And we quite easily can have a fastpath execution step that skips
these checks if no needed.

I suspect there might still be some cases where it's worth either using
the current parameter replacement, or rely on eval_const_expressions
based infrastructure to directly "inline" reference parameters if
safe. The latter seems a bit nicer / more extensible.

> I might be showing my grad school background here, but I'd be inclined to
> call it a LambdaExpr. A name based on "with" would be fine in a green
> field, but IMO we've got too much baggage from nodes related to SQL WITH.

That'd work as well for me.

Greetings,

Andres Freund