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. Greetings, Andres Freund
