Joachim Wieland <joe@mcknight.de> writes:
> On Tue, Nov 23, 2004 at 10:33:50AM -0500, Tom Lane wrote:
>> We do need to do something about the fact that EXECUTE can't access
>> plpgsql variables, though I'm afraid that fixing that is going to
>> require a rather complete overhaul of plpgsql :-(. But it needs one
>> anyway.
> Why do you think that it would be difficult to do it with the existing code?
Because the parsing context all gets thrown away, in particular the
namespace stack; so you can't tell what set of variables ought to be
visible to the EXECUTE.
> Which other limitations are there in the current implementation of pl/pgsql?
Its memory management really sucks. Function parsetrees ought to be put
into private contexts, not malloc'd, so that they can reasonably be
freed when the function is deleted or redefined. Likewise for the
cached query plans. Also we need a way to discard cached query plans
when relevant object definitions change (though this is not plpgsql's
fault in particular, it's a generic problem).
Another issue is that we need a better solution for recursive plpgsql
functions. Function parsetrees have to be read-only (with the
exception of adding cached plans that weren't there before) during
execution, else recursive functions don't work right. We have a really
ugly and inefficient answer to this, and I'm not even sure that it
covers 100% of the cases (at one time it definitely didn't, but I can't
recall right now if that got fixed completely). I'm not entirely sure
what a cleaner answer would look like, but I know I don't like it now.
regards, tom lane
