Re: Better support for whole-row operations and composite types

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

Let me know what you find out --- if I missed a trick on compatibility,
there's still plenty of time to fix it.

>> ... 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.

If we have just one datatype, how will the parser determine the type of
a "foo[subscript]" expression? After thinking a bit, I don't see how to
do that except by adding an out-of-line decoration to the underlying
type, somewhat like we do for "setof" or atttypmod. This is doable as
far as the backend itself is concerned, but the compatibility
implications for clients and user-written extensions seem daunting :-(

regards, tom lane