Re: WIP patch: convert SQL-language functions to return tuplestores - Mailing list pgsql-hackers
From | Pavel Stehule |
---|---|
Subject | Re: WIP patch: convert SQL-language functions to return tuplestores |
Date | |
Msg-id | 162867790810292258m18c2987ayfe29fe545f80ea27@mail.gmail.com Whole thread Raw |
In response to | Re: WIP patch: convert SQL-language functions to return tuplestores ("Robert Haas" <robertmhaas@gmail.com>) |
Responses |
Re: WIP patch: convert SQL-language functions to return tuplestores
|
List | pgsql-hackers |
2008/10/30 Robert Haas <robertmhaas@gmail.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 >
pgsql-hackers by date: