Re: Better support for whole-row operations and composite

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>So you mean like an array, but with possibly mixed datatypes?
>>'{1 , "abc def", 2.3}'
>>Seems to make sense.
> 
> The unresolved question in my mind is how to represent NULL elements.
> However, we have to solve that sooner or later for arrays too.  Any
> thoughts?

Good point. What's really ugly is that the external representation of 
string types differs depending on whether quotes are needed or not. If 
strings were *always* surrounded by quotes, we could just use the word 
NULL, without the quotes.

>>Another option might be to use the ROW keyword, something like:
>>ROW[1 , 'abc', 2.3]
> 
> 
> This is a separate issue, just as the ARRAY[] constructor has different
> uses from the array I/O representation.  I do want some kind of runtime
> constructor, but ROW[...] doesn't get the job done because it doesn't
> provide any place to specify the rowtype name.  Maybe we could combine
> ROW[...] with some sort of cast notation?
> 
>     ROW[1 , 'abc', 2.3] :: composite_type_name
>     CAST(ROW[1 , 'abc', 2.3] AS composite_type_name)
> 
> Does SQL99 provide any guidance here?

The latter seems to agree with 6.12 (<cast specification>) of SQL2003. 
I'd think we'd want the former supported anyway as an extension to standard.

> Almost.  I ended up keeping TupleDescGetSlot as a live function, but its
> true purpose is only to ensure that the tupledesc gets registered with
> the type cache (see BlessTupleDesc() in CVS tip).  The slot per se never
> gets used.  I believe that CVS tip is source-code-compatible with
> existing SRFs, even though I adjusted all the ones in the distribution
> to stop using the TupleTableSlot stuff.

Almost compatible. I found that, to my surprise, PL/R compiles with no 
changes after your commit. However it no segfaults (as I expected) on 
composite type arguments. Should be easy to fix though (I think, really 
haven't looked at it hard yet).

> The main point though is that row Datums now contain sufficient info
> embedded in them to allow runtime type lookup the same as we do for arrays.

Sounds good to me.

> There are several in the PL sources now, for instance plpgsql does this
> with an incoming rowtype argument:

Perfect -- thanks.

>>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?
> 
> Hmm, messy ...
> 
> I wonder now whether we still really need a separate pg_type entry for
> every array type.  The original motivation for doing that has been at
> least partly subsumed by storing element type OIDs inside the arrays
> themselves.  I wonder if we could go over to a scheme where, say,
> atttypid is the base type ID and attndims being nonzero is what you
> check to find out it's really an array of atttypid.  Not sure how we
> could map that idea into function and expression args/results, though.

Hmmm. I had thought maybe we could use a single datatype (anyarray?) 
with in/out functions that would need to do the right thing based on the 
element type. This would also allow, for example, arrays-of-arrays, 
which is the way that SQL99/2003 seem to allow for multidimensional arrays.

> Plan B would be to go ahead and create array types.  Not sure I would
> want to do this for table rowtypes, but if we did it only for CREATE
> TYPE AS then it doesn't sound like an unreasonable amount of overhead.

I was hoping we wouldn't need to do that.

Joe