Joe Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
