Re: Better support for whole-row operations and composite

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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