Re: modifying the tbale function
От | Tom Lane |
---|---|
Тема | Re: modifying the tbale function |
Дата | |
Msg-id | 29048.1174351717@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: modifying the tbale function ("Florian G. Pflug" <fgp@phlo.org>) |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: