Palle Girgensohn <girgen@pingpong.net> writes:
> Ah, sorry. Other sessions get the error immediately as well though. Would input parameters matter, or is it just the
returntype? I'll see if I can find a test case that breaks permanently, but I'm probably mistaken about that bit then.
It's not the return value as such that's choking, it's the local
variable. I believe the issue would appear with any local variable or
parameter of a named composite type.
The general case of this is quite difficult: should we expect that an
ALTER TYPE done (perhaps in some other session) while a function is
running would affect the *current value* of such a local variable?
There's really no practical way to implement that in the current system
structure, and certainly no way to enforce the behavior you get for row
values in regular tables, namely that the ALTER TYPE rolls back if any
row value conversion fails.
However I think we could realistically hope that subsequent function
calls would work with the up-to-date rowtype definition. My opinion
about how to do that is to stop using the "row" code path in plpgsql for
values of named composite types, and instead treat them as "records";
that is, store a HeapTuple value plus a tuple descriptor (or something
morally equivalent such as a TupleTableSlot) and not break the value up
into a separate plpgsql variable (a/k/a PLpgSQL_datum) per column. The
fundamental problem here is that doing that bakes the rowtype's column
set into the compiled form of the function.
There was some objection to that in the previous discussion on the
grounds of possible performance loss, but I think that objection is
at best premature; it ignores some salient facts such as
(1) some operations would get faster not slower,
(2) there is scope for performance-improvement efforts,
(3) per the old saying, code can be arbitrarily fast if it doesn't have to give the right answer. Objecting to this
fixwithout proposing a more-workable alternative is useless.
regards, tom lane
