Thread: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable
why copy tuple in the end of trigger when nothing changed in NEW OLD record variable
From
"billy"
Date:
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
Re: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable
From
Tom Lane
Date:
"billy" <billywq@163.com> writes:
> I think we can add some judgment conditions in function plpgsql_exec_trigger() to avoid this problem.
I don't especially see the point of adding extra complexity here.
AFAICS you are talking about avoiding one or two palloc/pfree
cycles, which is surely down in the noise compared to the cost of
calling a plpgsql trigger.
regards, tom lane
Re: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable
From
"billy"
Date:
Tom Lane,
er, your explanation is reasonable.
But at least the comment if (newtuple != tuple) /* modified by Trigger(s) */ { ..... is likely to misdirect us.
It took me a few hours to figure it out. :-(
======= 2008-06-10 23:43:00 In your letter you say:=======
>"billy" <billywq@163.com> writes:
>> I think we can add some judgment conditions in function plpgsql_exec_trigger() to avoid this problem.
>
>I don't especially see the point of adding extra complexity here.
>AFAICS you are talking about avoiding one or two palloc/pfree
>cycles, which is surely down in the noise compared to the cost of
>calling a plpgsql trigger.
>
> 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
billy
billywq@163.com
2008-06-11