issues with dropped columns in plpgsql code again

sorry

my test

create table f1(a int, b int, c varchar, dropped_column numeric, d varchar);

create or replace function f1_trg()
returns trigger as $$
declare _f1_var f1;
begin raise notice 'run trigger';
_f1_var := new;
return _f1_var;
end;
$$ language plpgsql;

create trigger xx before insert on f1 for row execute procedure f1_trg();

insert into f1 values(1,1,'aaa',1.1,'aaa');
alter table f1 drop column dropped_column ;

insert into f1 values(1,1,'aaa','aaa');

2013/5/7 Pavel Stehule <pavel.stehule@gmail.com>

On 7 May 2013 21:23, Pavel Stehule <pavel.stehule@gmail.com> wrote:

sorry

my test

create table f1(a int, b int, c varchar, dropped_column numeric, d
varchar);

create or replace function f1_trg()
returns trigger as $$
declare _f1_var f1;
begin raise notice 'run trigger';
_f1_var := new;
return _f1_var;
end;
$$ language plpgsql;

create trigger xx before insert on f1 for row execute procedure f1_trg();

insert into f1 values(1,1,'aaa',1.1,'aaa');
alter table f1 drop column dropped_column ;

insert into f1 values(1,1,'aaa','aaa');

Fails for me as well. I managed to run the last query either with
restarting session, or disabling the trigger.

Checked that on PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2, 64-bit

regards,
Szymon

Pavel Stehule <pavel.stehule@gmail.com> writes:

One user reported a issues with triggers related to dropped columns.
When I checked his code, I found a more possible problems.

This is just the same kind of modified-rowtype problem we've discussed
before.

I continue to maintain that the only realistic fix is to stop using the
PLPGSQL_DTYPE_ROW infrastructure for variables of externally-defined
composite types. In the last go-round, this was rejected on the
(unproven) assumption that it would make things slower. But as a wise
man once said, you can make code arbitrarily fast if it doesn't have to
give the right answer.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Dne 10.5.2013 22:17 "Tom Lane" <tgl@sss.pgh.pa.us> napsal(a):

Pavel Stehule <pavel.stehule@gmail.com> writes:

One user reported a issues with triggers related to dropped columns.
When I checked his code, I found a more possible problems.

This is just the same kind of modified-rowtype problem we've discussed
before.

Yes. It is same problém.

I continue to maintain that the only realistic fix is to stop using the
PLPGSQL_DTYPE_ROW infrastructure for variables of externally-defined
composite types. In the last go-round, this was rejected on the
(unproven) assumption that it would make things slower. But as a wise
man once said, you can make code arbitrarily fast if it doesn't have to
give the right answer.

Yes. It is probably solutions.

Regards

Pavel