"Florian G. Pflug" <fgp@phlo.org> 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
legal.
regards, tom lane
