Re: Better support for whole-row operations and composite

Tom Lane wrote:
> We have a number of issues revolving around the fact that composite
> types (row types) aren't first-class objects. I think it's past time
> to fix that. Here are some notes about doing it. I am not sure all
> these ideas are fully-baked ... comments appreciated.

[Sorry for the delay in responding]

Nice work, and in general it makes sense to me. A few comments below.

> We will be able to make generic I/O routines for composite types,
> comparable to those used now for arrays. Not sure what a convenient
> external format would look like. (Possibly use the same conventions
> as for a 1-D array?)

So you mean like an array, but with possibly mixed datatypes?

'{1 , "abc def", 2.3}'

Seems to make sense.

Another option might be to use the ROW keyword, something like:

ROW[1 , 'abc', 2.3]

> We could also think about allowing functions that are declared as
> accepting RECORD (ie, polymorphic-across-row-types functions). They
> would use the same methods already used by polymorphic functions to
> find out the true types of their inputs. (Might be best to invent a
> separate pseudotype, say ANYRECORD, rather than overloading RECORD
> for this purpose.)

Check. I really like this idea.

> TupleDescGetSlot: no-op, returns NULL TupleGetDatum: ignore slot,
> return tuple t_data pointer as datum
>
> This will work because heap_formtuple and BuildTupleFromCStrings can
> return a HeapTuple whose t_data part is already a valid row Datum,
> simply by setting the appropriate length and type fields in it. (If
> the tuple is ever stored to disk as a regular table row, these fields
> will be overwritten with xmin/cmin info at that time.)

Is this the way you did things in your recent commit?

> To convert a row Datum into something that can be passed to
> heap_getattr, one could use a local variable of type HeapTupleData
> and set its t_data field to the datum's pointer value. t_len is
> copied from the datum contents, while the other fields of
> HeapTupleData can just be set to zeroes.

I think I understand this, but an example would help.

> * We have to be able to re-use an already-existing cache entry if it
> matches a requested TupleDesc.

For anonymous record types, how will that lookup be done efficiently?
Can the hash key be an array of attribute oids?

> If an ALTER TABLE command does something that requires examining or
> changing every row of a table, it would presumably have to do the
> same to all entries in any composite-type column of the table's
> rowtype. To avoid surprises and interesting debates about who has
> permissions to do this, it might be wise to restrict on-disk
> composite columns to be only of standalone composite types (ie, those
> made with CREATE TYPE AS). This restriction would also avoid debates
> about whether table constraints apply to composite-type columns.

I agree.

As an aside, it would be quite useful to have support for arrays of
tuples. Any idea on how to do that without needing to define an explicit
array type for each tuple type?

Joe