Re: Inlining functions with "expensive" parameters - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inlining functions with "expensive" parameters
Date
Msg-id 8764.1510864079@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inlining functions with "expensive" parameters  (Andres Freund <andres@anarazel.de>)
Responses Re: Inlining functions with "expensive" parameters  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On November 16, 2017 11:44:52 AM PST, Tom Lane <tgl@sss.pgh.pa.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
evaluatesparameters and then executes the child expression. I'm thinking of doing this hierarchically so there's less
issueswith 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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Issues with logical replication
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted