I wrote:
> I'm currently going to have a look at just what it would take to support
> both lazy and eager evaluation in functions.c (independently of what
> syntax, if any, we settle on to expose the choice to the user). If it's
> either really awful or really easy we should know that before arguing
> further.
Attached is a draft patch that allows SQL functions to return sets using
either value-per-call or materialize mode. It does not expose any
control to the user; for the moment, the choice is driven by whether the
call site is ExecMakeFunctionResult (which prefers value-per-call) or
ExecMakeTableFunctionResult (which prefers materialize). I estimate
that functions.c is two or three hundred lines longer than it would be
if we stripped the value-per-call support and simplified the logic down
to what I had in my prior patch. Which is not all that much in the
big scheme of things, so I'll withdraw my argument for simplifying.
I'm not sure if it's worth adding a control knob or not --- it's still
true that materialize is faster on a tuple-by-tuple basis, but whether
the difference is all that significant for nontrivial queries is
debatable. Anyway I don't really want to work on that point right now.
The next step is to make it actually support RETURNING queries, and if
I don't get on with that I won't finish it before commitfest.
regards, tom lane