Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Taking it a bit further...
>
> There are (at least) two distinct problems involved here. One is
> getting plpgsql to deal correctly with rowtypes that include dropped
> columns. The other is getting it to react when someone alters a table
> whose rowtype is relied on by already-compiled functions.
>
> The former problem is just a small matter of programming in plpgsql;
> I'm not sure what the best way to do it is, but it's clearly just
> plpgsql's issue. The latter problem calls for a ton of infrastructure
> that we haven't got :-(
Hmm, well...
- Keeping timestamps of when the table definition was last changed and
when the function was last compiled, and then having the language
interpreter check the two before executing the function (and
recompile it when the function is out of date) would solve the
problem (and require relatively little additional infrastructure),
but I would expect the performance hit to be too high to be worth
it.
- Alternatively, the language compiler could record a dependency
between the function and the table (assuming this isn't done
already), and be told to recompile the function when the table
definition changes. This gets real messy when you're talking about
doing this in a transaction, unless the compilation itself is
something that can be rolled back (it wouldn't surprise me in the
least if the compiled definition is stored in a table already and
thus can be rolled back).
- Alternatively, recompilation could be made a manual thing,
e.g. ALTER FUNCTION blah RECOMPILE. It would still be a win for
this to be transaction-capable.
--
Kevin Brown [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
