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

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

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores
Date: 2008-10-30 00:42:38
Message-ID: 603c8f070810291742l4026b931lebc179626bc5b937@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> All of this is pie-in-the-sky for PL functions, and I think properly so:
> the whole reason for supporting PLs is to enable doing things that SQL
> does poorly or not at all.  So expecting SQL to interoperate very
> closely with them seems impossible, or at least unreasonably limiting.
> The real issue at hand is what to do with SQL-language functions.
>
> I'm currently going to have a look at just what it would take to support
> both lazy and eager evaluation in functions.c (independently of what
> syntax, if any, we settle on to expose the choice to the user).  If it's
> either really awful or really easy we should know that before arguing
> further.

It occurs to me that for PL/perl and similar one could design an
interface that is similar to the one that is used for C functions -
that is, function is invoked multiple times, returns one value per
call, and is given a place to stash its state across calls.  For
example, for PL/perl, you could pass a mutable empty hash reference on
the first call and then pass the same hash reference back on each
subsequent call.  That wouldn't require being able to freeze/thaw the
whole state, just being able to maintain the contents of that hash
reference across calls.

It would probably be a lot more difficult to make something like this
work usefully for PL/pgsql, which as a language is rather underpowered
(nonetheless I use it heavily; it's awesome for the things it is good
at), but I suspect it could be applied to Python, PHP, etc. pretty
easily.

So that's at least three ways you can evaluate the function: generate
the whole thing in one fell swoop, single function call but with lazy
execution, or value-per-call mode.  I'm guessing someone could dream
up other possibilities as well.  Now, who's volunteering to implement?
 :-)

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Koichi SuzukiDate: 2008-10-30 00:46:10
Subject: Re: Proposal of PITR performance improvement for 8.4.
Previous:From: Josh BerkusDate: 2008-10-29 21:26:09
Subject: Please make sure your patches are on the wiki page

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