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

Le mardi 28 octobre 2008, Pavel Stehule a écrit :
> 2008/10/28 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
> > Hi,
> >
> > In the python language, functions that lazily return collections are
> > called generators and use the yield keyword instead of return.
> > http://www.python.org/doc/2.5.2/tut/node11.html#SECTION001110000000000000
> >00000
> >
> > Maybe having such a concept in PostgreSQL would allow the user to choose
> > between current behavior (materializing) and lazy computing, with a new
> > internal API to get done in the executor maybe.
>
> lazy computing is good idea, but I am afraid so it should be really
> wery hard implemented. You should to store somewhere current state,
> stop execution, return back from node, and you should be able restore
> PL state and continue in process. I can't to see it without thread
> support.

I'm not sure to understand what is the current situation then. By reading this
Tom's commit message
Extend ExecMakeFunctionResult() to support set-returning functions that
return via a tuplestore instead of value-per-call
...
For the moment, SQL functions still do things the old way.

http://git.postgresql.org/?p=postgresql.git;a=commit;h=6d5301be5ece6394433d73288e0fafaed6326485

I had the impression we already have a lazy implementation, this
value-per-call returning code path, which still exists for SQL functions.

> > CREATE FUNCTION my_generator_example(integer, integer)
> > returns setof integer
> > generator
> > language SQL
> > $f$
> > SELECT generate_series($1, $2);
> > $f$;

So my idea would be to have the SQL function behavior choose to return values
either via tuplestore or via value-per-call, depending on the user
setting "generator" or "lazy".
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.

Current behaviour would then mean the default depends on the language, lazy
for SQL and tuplestore for PL/pgSQL. Well, it will have to be documented,
whatever the final choice is.

Is it possible? A good idea?
--
dim