"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> There might be trouble if a second function has to be executed with
> the same PL as an already running (but currently "stopped")
> function. This would only work for PL that is thread-safe in some way.

Seems a bit iffy.

It strikes me that at least for plpgsql, it might be possible to support
value-per-call mode without any thread support.  What you'd need to do
is get rid of the current arrangement whereby the control structure of
the plpgsql code is modeled on-the-fly by the call stack of the C code,
and instead have block nesting, loops, etc represented by explicit data
structures that're manipulated by C code with a flat call stack.  If the
function wants to do a RETURN NEXT, you just return, leaving its current
state all nicely tucked in a data structure.  This would be a little
tedious but is in principle a straightforward change.  I'm not sure if
there'd be any meaningful performance impact.

The tricky part is what about exception handling?  If the function does
RETURN NEXT inside a BEGIN/EXCEPTION block, what do you do ... what does
that even mean?  There be equally nasty dragons lurking behind that
question for a threaded implementation, of course.  It might be that we
could get away with decreeing that RETURN NEXT inside EXCEPTION isn't

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to