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

- 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])

Reply via email to