On Thu, Nov 16, 2017 at 12:37 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2017-11-16 15:27:59 -0500, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On November 16, 2017 11:44:52 AM PST, Tom Lane <t...@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 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. > Is there a github branch or an active patch set where this work is going on that I could watch and learn from? Thanks! P > Greetings, > > Andres Freund >
