Thanks for looking Tom !
Yeah, I have looked at the PLPGSQL_DTYPE_REC code path and that looks hard.
Let me look at the recompilation angle, if I have a fix of some sort I'll
let you know.
peter
On Tue, Dec 8, 2015 at 1:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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
>
