Re: WIP patch: convert SQL-language functions to return tuplestores

Dimitri Fontaine <dfontaine@hi-media.com> writes:
> And I fail to see how the user would control which behavior will get chosen, 

Oh, I'm sorry, I didn't realize you misunderstood my syntax example.
I was suggesting that the SQL function manager recognize some optional
non-SQL keywords at the start of a SQL function body, along the lines of

CREATE FUNCTION foo(...) RETURNS SETOF something AS $$
#option eager
SELECT ... $$ LANGUAGE SQL;

versus

CREATE FUNCTION foo(...) RETURNS SETOF something AS $$
#option lazy
SELECT ... $$ LANGUAGE SQL;

(I'm not wedded to this particular spelling of it, but there is
precedent in plpgsql.)

Now of course the bigger problem with either this syntax or yours is
that attaching such a property to a function is arguably the Wrong Thing
in the first place.  Which one is the best way is likely to depend on
the calling query more than it does on the function.  However, I see no
solution to that problem except function inlining; and if the function
gets inlined then all this discussion is moot anyhow.
        regards, tom lane