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
