Joe Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
