Tom Lane wrote:
> If you use that, it will look just the same as the existing situation
> where you are declared to return RECORD and someone calls you with
> a column name/type list in FROM. Whether you want any additional
> smarts is up to you.
>
>
>>- The TupleDesc returned by the get_call_result_type() is not always
>>reachable using an Oid. I.e. I cannot use TypeGetTupleDesc(oid, NIL)
>>with the Form_pg_proc.prorettype of my function as the first argument.
>
>
> That was true before for the RECORD case.
>
PL/Java will not handle the RECORD case gracefully at present I'm
afraid. The 8.0 compatible version will need some improvements. How is
the TupleDesc obtained in case of RECORD in 8.0.x? Is it the same in 7.4?
>
>>- The Form_pg_proc.pronargs denotes the number of IN parameters, i.e.
>>its safe to access proargtypes.values[idx] with an idx ranging from 0 to
>>pronargs - 1.
>
>
> Right, pronargs/proargtypes still denote the call signature and thus
> only count IN (and INOUT) parameters.
>
> One thing to be a bit wary of is that when OUT arguments are present,
> subscripts in proargnames line up with proallargtypes not proargtypes.
> I dunno if you are using proargnames at all, but if you are, the code
> is likely to misbehave if it doesn't know that.
>
Thanks a lot. Now I know how to go about this. Seems pretty stright
forward. Nice work!
Regards,
Thomas Hallgren
