Обсуждение: 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

"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

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