Re: Better support for whole-row operations and composite
От | Tom Lane |
---|---|
Тема | Re: Better support for whole-row operations and composite |
Дата | |
Msg-id | 20581.1081052733@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Better support for whole-row operations and composite (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Better support for whole-row operations and composite
|
Список | 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 по дате отправления: