Re: Better support for whole-row operations and composite - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Better support for whole-row operations and composite
Date
Msg-id 20581.1081052733@sss.pgh.pa.us
Whole thread Raw
In response to Re: Better support for whole-row operations and composite  (Joe Conway <mail@joeconway.com>)
Responses Re: Better support for whole-row operations and composite
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
>> Any ideas why the trigger tuple type isn't registered, or what I'm doing 
>> wrong?

> A little more info on this. It appears that the tuple type is set to 
> either 2249 (RECORDOID) or 0.

After further thought, we could possibly make it work for BEFORE
triggers, but there's just no way for AFTER triggers: in that case what
you are getting is an image of what went to disk, which is going to
contain transaction info not type info.

If you really want the trigger API for PL/R to be indistinguishable from
the function-call API, then I think you will need to copy the passed
tuple and insert type information.  This is more or less what
ExecEvalVar does now in the whole-tuple case (the critical code is
actually in heap_getsysattr though):
               HeapTupleHeader    dtup;
               dtup = (HeapTupleHeader) palloc(tup->t_len);               memcpy((char *) dtup, (char *) tup->t_data,
tup->t_len);
               HeapTupleHeaderSetDatumLength(dtup, tup->t_len);               HeapTupleHeaderSetTypeId(dtup,
tupleDesc->tdtypeid);              HeapTupleHeaderSetTypMod(dtup, tupleDesc->tdtypmod);
 
               result = PointerGetDatum(dtup);
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Better support for whole-row operations and composite types
Next
From: Joe Conway
Date:
Subject: Re: Better support for whole-row operations and composite