Re: Better support for whole-row operations and composite

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