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

pgsql-hackers=A3=AChello:


	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 =3D 3;



	after execution:

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

	we come to function ExecUpdate():

    HeapTuple newtuple;
    newtuple =3D 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 !=3D tuple) /* modified by Trigger(s) */
	  {

 	is FALSE for ever.



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


=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1billy
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1billywq@[EMAIL PROTECTED]
 via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers