I see... but anyway this bug does not allow use return record value from a trigger in table contained at least one dropped column, and even worse trigger will work on fresh loaded copy of production database and would pass all possible tests, but on production database it is stop working. Moreover, full functional system can become broken if single column dropped from table contained such trigger. E.g. functionality of such trigger depends of dropped column history of the table, which is wrong (IMHO).
I was tried another test trigger on table with dropped column, and get even more funny results (trigger awaiting return record contained all rows from table include dropped so I tried construct such record): CREATE OR REPLACE FUNCTION test_function() RETURNS trigger AS $$ DECLARE _row record; BEGIN RAISE NOTICE 'NEW record = %', NEW; SELECT *,2,3 INTO _row FROM test limit 1; RAISE NOTICE '_row record = %', _row; RETURN _row; END; $$ LANGUAGE plpgsql; postgres=# insert into test values (1); NOTICE: NEW record = (1) NOTICE: _row record = (1,2,3) ERROR: returned row structure does not match the structure of the triggering table DETAIL: Returned type integer does not match expected type N/A (dropped column) in column "........pg.dropped.2........". CONTEXT: PL/pgSQL function "test_function" during function exit I think changes in 9.0 now mask actual bug instead of fix it. If I was wrong, still would be useful to know how to use return record from trigger function in that case, because I can't make a working version at all. On Mon, Jun 14, 2010 at 4:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Maksym Boguk" <maxim.bo...@gmail.com> writes: >> This bug hard to describe. But in general if a table contained dropped >> columns you cannot use return record variable in trigger function. > > This is fixed for 9.0 ... or at least the specific test case you provide > doesn't fail. We have not risked back-porting the change though, > because there are other aspects of what the new code does that might > cause people problems, eg > http://archives.postgresql.org/pgsql-hackers/2010-03/msg00444.php > http://archives.postgresql.org/message-id/6645.1267926...@sss.pgh.pa.us > > regards, tom lane > -- Maxim Boguk Senior Postgresql DBA. Skype: maxim.boguk Jabber: maxim.bo...@gmail.com LinkedIn profile: http://nz.linkedin.com/in/maximboguk МойКруг: http://mboguk.moikrug.ru/ Сила солому ломит, но не все в нашей жизни - солома, да и сила далеко не все. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
