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.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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:
Show quoted text
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