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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "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 15:38:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Le mercredi 29 octobre 2008, Tom Lane a écrit :
> Well, call-per-value is *necessary* for lazy evaluation, but it's not
> *sufficient*.  You need a function implementation that can suspend and
> resume execution, and that's difficult in general.

Ok, I think I begin to understand how things are tied together. Thanks again 
for your patience explaining :)

> Well, we'd just tweak how the executor gets called inside functions.c.
> The main problem is that we'd have to have two different sets of
> behavior there, depending on whether we are trying to evaluate commands
> a row at a time or all at once, plus interlocks to disallow cases like
> using LAZY with a RETURNING query.  It's certainly possible but I
> believe it will make functions.c a lot longer and uglier than it would
> be without it.

And I fail to see how the user would control which behavior will get chosen, 
which I think was part of the "going further with your ideas" sub thread.

> Nobody has refuted the argument that sticking a LIMIT into the function
> would accomplish the same result.

Fair enough.

> > What's against PLpgSQL implementing a YIELD statement?
> Feel free to try it, if you want.

Hehe, not this year.
But being able to ask questions and get clarifications from hackers certainly 
is a step in this direction. Feeling ready and organizing one's time around 
it is the next :)

> When you get done you might have some 
> grasp of why it'll be nearly impossible for PLs that we don't control
> the entire implementation of.

Hence the YIELD / new API idea, with the LAZY property which would be optional 
for PLs and only implemented in plpgsql (and maybe plpython, as python 
supports the generator functions concept) first.
Maybe having optional features for PLs has not yet been done?

But again, I was started in this only by misunderstanding your call here:

 > I think the PL side of the problem is the hard part --- if we knew how
 > to solve these issues for plpgsql then SQL functions would surely be
 > easy.

I'm not being sticky on the feature request, just struggling to understand 
correctly the issues at hand, recognizing that easy choice of EAGER or LAZY 
function evaluation would be great as a user, even if unsupported in a number 
of PLs.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-29 15:58:19
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores
Previous:From: Tom LaneDate: 2008-10-29 15:07:43
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores

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