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

Started by billyover 17 years ago3 messages
#1billy
billywq@163.com

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: billy (#1)
Re: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable

"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

#3billy
billywq@163.com
In reply to: Tom Lane (#2)
Re: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable

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