Hello,
I think the comment just above the HeapTupleFields struct definition
has the related details.
/** Heap tuple header. To avoid wasting space, the fields should be* laid out in such a way as to avoid structure
padding.**Datums of composite types (row types) share the same general structure* as on-disk tuples, so that the same
routinescan be used to build and* examine them. However the requirements are slightly different: a Datum* does not
needany transaction visibility information, and it does need* a length word and some embedded type information. We can
achievethis* by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple* with the fields needed in the Datum
case. Typically, all tuples built* in-memory will be initialized with the Datum fields; but when a tuple is* about to
beinserted in a table, the transaction fields will be filled,* overwriting the datum fields.
especially the last line points as to what roles each of them plays,
though, I would like to hear more about additional details from others
who might reply.
On Mon, May 20, 2013 at 4:28 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:
> Dear Hackers
>
> In fix part oh HeapTuple, there is a union that is named t_choice,
> union
> {
> HeapTupleFields t_heap;
> DatumTupleFields t_datum;
> } t_choice;
>
> I can't find out why we need t_datum, actually there is no comment about
> DatumTupleFields.
>
> Regards
> Soroosh
>
>
--
Amit Langote
