Skip site navigation (1) Skip section navigation (2)

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

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores
Date: 2008-10-29 10:53:57
Message-ID: 200810291154.00224.dfontaine@hi-media.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-29 11:58:31
Subject: Re: UUID-OSSP Contrib Module Compilation Issue
Previous:From: Simon RiggsDate: 2008-10-29 10:20:45
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1155)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group