> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
