Re: Better support for whole-row operations and composite

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>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 still haven't had time to look closely, and well may have been doing 
something non-standard all along, but in any case this is the current 
failing code:
  else if (function->arg_is_rel[i])  {    /* for tuple args, convert to a one row data.frame */    TupleTableSlot *slot
=(TupleTableSlot *) arg[i];    HeapTuple        tuples = slot->val;    TupleDesc        tupdesc =
slot->ttc_tupleDescriptor;
    PROTECT(el = pg_tuple_get_r_frame(1, &tuples, tupdesc));  }

The problem was (I think -- I'll check a little later) that 
slot->ttc_tupleDescriptor is now '\0'.

>>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 :-(

I'll think-about/play-with this some more, hopefully this weekend.

Thanks,

Joe