From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, "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 05:58:33 |
Message-ID: | 162867790810292258m18c2987ayfe29fe545f80ea27@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2008/10/30 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> 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?
> :-)
>
With session variables we could implement srf function in plpgsql like
current C srf function. Like
create or replace function foo(....)
returns record as $$
#option with_srf_context(datatype of srf context)
begin
return row(...);
end;
$$ language plpgsql;
I thing it is implementable, but It's not very efective. There are lot
of initialisation code. But this technique is used for agregation
functions without problems. I belive, so it's should not be fast, but
it could be usefull for very large datasets, where current srf
functions should fail.
regards
Pavel Stehule
> ...Robert
>
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2008-10-30 06:06:34 | Re: pre-MED |
Previous Message | David Fetter | 2008-10-30 04:49:10 | Re: pre-MED |