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  (Joe Conway <mail@joeconway.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Better support for whole-row operations and composite types
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Better support for whole-row operations and composite