Why there is a union in HeapTupleHeaderData struct

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 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

--
Amit Langote

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Thanks,

If a tuple constructed in memory we don't need t_heap. I have another
question,
How make an in-memory tuple?

On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>wrote:

Hello,

I think a more appropriate question to be asked here would be at what
point (in the life of a typical tuple), does a tuple's header contain
t_datum or otherwise, which I would also like to be answered.

On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:

Thanks,

If a tuple constructed in memory we don't need t_heap. I have another
question,
How make an in-memory tuple?

On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>
wrote:

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 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

--
Amit Langote

--
Amit Langote

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Wonder though if this question is better asked in pgsql-novice?

On Mon, May 20, 2013 at 9:23 PM, Amit Langote <amitlangote09@gmail.com> wrote:

Hello,

I think a more appropriate question to be asked here would be at what
point (in the life of a typical tuple), does a tuple's header contain
t_datum or otherwise, which I would also like to be answered.

On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:

Thanks,

If a tuple constructed in memory we don't need t_heap. I have another
question,
How make an in-memory tuple?

On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>
wrote:

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 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

--
Amit Langote

--
Amit Langote

--
Amit Langote

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Sent from my iPad

On 20-May-2013, at 18:14, Amit Langote <amitlangote09@gmail.com> wrote:

Wonder though if this question is better asked in pgsql-novice?

On Mon, May 20, 2013 at 9:23 PM, Amit Langote <amitlangote09@gmail.com> wrote:

Hello,

I think a more appropriate question to be asked here would be at what
point (in the life of a typical tuple), does a tuple's header contain
t_datum or otherwise, which I would also like to be answered.

On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:

Thanks,

If a tuple constructed in memory we don't need t_heap. I have another
question,
How make an in-memory tuple?

On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>
wrote:

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 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

I don't think so, as this involves internal structures.Let's keep it here.

Regards,

Atri

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hello,

Would you guys please trim the quoted text of the emails you're replying
to? I understand Gmail is obnoxious w.r.t. quoted text, but this is
starting to become excessive.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, May 20, 2013 at 8:54 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Hello,

Would you guys please trim the quoted text of the emails you're replying
to? I understand Gmail is obnoxious w.r.t. quoted text, but this is
starting to become excessive.

Oops, I didnt notice that. Sorry!

Regards,

Atri

--
Regards,

Atri
l'apprenant

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers