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 routines can be used to build and * examine them. However the requirements are slightly different: a Datum * does not need any transaction visibility information, and it does need * a length word and some embedded type information. We can achieve this * 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 be inserted 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 > >
