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
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
