On 2017-11-21 09:59:00 -0500, Robert Haas wrote: > On Thu, Nov 16, 2017 at 2:51 PM, Andres Freund <and...@anarazel.de> wrote: > > 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. > > 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?
It'll work in some of those cases. But you e.g. can't use an InitPlan to reference to a table's columns without some major contortions, no? Inlining stuff like SELECT * FROM foo WHERE sql_func(foo.blarg, anotherfunc()); is pretty important for some usecases. The re-evaluation concern's also there, this should also work with e.g. volatile parameters like nextval(), without establishing a second mechanism to deal with them. Greetings, Andres Freund
