pplachta@gmail.com writes:
> create type complex as (a1 int, a2 numeric, a3 text, a4 int, a5 int);
> create or replace function foo(arg complex) returns complex as $$
> begin
> return ( select arg );
> end; $$ language plpgsql;
> alter type complex drop attribute a4;
> [ foo() stops working ]
Yeah, the problem is that since "arg" has a named composite type, it is
handled using the PLPGSQL_DTYPE_ROW code path, which sets up a plpgsql
Datum for each column at function compile time. So the rowtype is baked
into the function at that point. If you start a fresh session everything
is fine.
A real fix might involve switching over to the PLPGSQL_DTYPE_REC code
path, which I've advocated for for some time but it'd be pretty invasive.
Or perhaps we could arrange to force recompilation of a plpgsql function
if any composite type it depends on has changed. Nobody's really gotten
excited enough about this to do either ...
regards, tom lane
