Обсуждение: BUG #13796: ALTER TYPE DROP COLUMN -- unexpected behavior ?
The following bug has been logged on the website: Bug reference: 13796 Logged by: Peter Plachta Email address: pplachta@gmail.com PostgreSQL version: 9.4.5 Operating system: mac os x Description: Here is a testcase: 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; -- modify type test alter type complex drop attribute a4; select foo(row(1, 1.1, 'one', 111)); ====================== The last one prints: foo -------------- (1,1.1,one,) (1 row) ====================== Why is the last element NULLed out? It's not like I can pass 5 elements to the function.
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
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 >