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

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Done this way, the user could also choose for the function to be lazy or to
> use a tuplestore whatever the language in which it's written.

The odds of this ever happening for any of the PLs are not
distinguishable from zero. It might be nice to have, but the amount of
work involved would be incredibly out of proportion to the benefits ---
even assuming that it's technically possible at all, which I rather
doubt for the PLs that depend on language interpreters that aren't under
our control.

So the fact that it's possible for SQL-language functions is an
idiosyncrasy of that language, not something we should cram into the
general CREATE FUNCTION syntax in the vain hope that having syntax
might cause an implementation to appear someday.

Therefore, if we were going to expose a knob to the user to control this
behavior, I'd be inclined to make it a part of the language-specific
syntax of SQL function bodies. We could take a hint from the
(underdocumented) #option syntax in plpgsql, something like

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

Mind you, I'm not exactly *for* this, because I think it will result
in making functions.c a whole lot more complex and hard to maintain
than it needs to be, in exchange for a behavior that I don't believe
is especially useful in most cases, and can easily be worked around
when it is useful. But if people are going to be sticky about the
point, something like this might be a workable compromise.

regards, tom lane