Tuesday, June 10, 2008

[HACKERS] why copy tuple in the end of trigger when nothing changed in NEW OLD record variable

Hi pghackers:

version 8.3.0 in function plpgsql_exec_trigger.

in a trigger, if NEW is returned as the result and we do nothing to NEW.


for example, we have a table like this:

create table test (a int);
insert into test values(1);

and a trigger like:

create or replace function test_trigger() returns trigger as $$
begin
return new;
end; $$language plpgsql;

create trigger before_update_test before update
on test for each row execute procedure test_trigger();


in this trigger, we don't change the value of NEW.

than execute:

update test set a = 3;

after execution:

/* Copy tuple to upper executor memory */
rettup = SPI_copytuple((HeapTuple) (estate.retval));

we come to function ExecUpdate():

HeapTuple newtuple;
newtuple = ExecBRUpdateTriggers(estate, resultRelInfo,
tupleid, tuple);

Since the trigger's return value is copied to another memory address, the newtuple is impossible equal to the oldtuple.

so the following condition:

if (newtuple != tuple) /* modified by Trigger(s) */
{

is FALSE for ever.

I think we can add some judgment conditions in function plpgsql_exec_trigger() to avoid this problem.


        billy
        billywq@163.com
          2008-06-11


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

No comments: