Re: [GENERAL] Bug and/or feature? Complex data types in

Tom Lane wrote:
>         int32 length word (overall length of datum)
>         OID type indicator (OID of the composite type)
>         header fields similar to a normal on-disk tuple
>         null bitmap if needed
>         values of fields (themselves also Datums)
> 
> It's possible we could leave out the type OID, but given that we found
> it useful to include an element type OID in array headers, I'm betting
> we want one for composite-type values too.  Without it, we must always
> know the exact composite type makeup from context.  (But see below.)

Makes sense. But see below...

> Now, this structure could be TOASTed as a whole, since it's just a
> varlena data type.  But we cannot expect the toasting routines to look
> inside it --- that would imply that it's not like other varlena data
> types after all.  That means that the contained fields had better not be
> out-of-line TOAST value references, because there's no way to keep track
> of them and keep from deleting the referenced value too soon.

Why wouldn't we handle this just like we do when we build an array from 
elemental datums (i.e. allocate sufficient space and copy the individual 
datums into the structure)?

Continuing the analogy:
    int32   size;      /* overall length of datum */    int     flags;     /* null-bitmap indicator, others reserved */
  Oid     relid;     /* OID of the composite type */    int16   t_natts;   /* number of attributes */    bits8
t_bits[1];/* null bitmap if needed */    Datum  *values     /* values of fields */
 

values would be built similar to how its done in 
construct_md_array/CopyArrayEls/ArrayCastAndSet

The overlying datatype would be similar to anyarray.

AFAICS SQL2003 (and SQL99) defines something similar to this as a "row 
type". It looks like this:
  ROW ( column definition list )

But it also seems to equate a table's-row type to a "row type" in 
section 4.8 (Row types):
  "A row type is a sequence of (<field name> <data type>) pairs, called 
fields. It is described by a row type descriptor. A row type descriptor 
consists of the field descriptor of every field of the row type.
  The most specific type of a row of a table is a row type. In this 
case, each column of the row corresponds to the field of the row type 
that has the same ordinal position as the column."

So maybe as an extension to the standard, we could allow something like:
  ROW composite_type_name

Example:

CREATE TABLE foo (id int, tup ROW (f1 int, f2 text));

or ...

CREATE TABLE bar (f1 int, f2 text);
CREATE TABLE foo (id int, tup ROW bar);

> The other point was that what's actually returned at the moment from a
> function-returning-tuple is a Datum that contains a pointer to a
> TupleTableSlot, not a pointer to a datum of this kind.

If you had something akin to arrayin/arrayout, would this still need to 
be changed?

Joe