Re: OUT parameters in PL/Java

Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> My compile failure was due to the change of proargtypes from Oid* to an
> oidvector. I initially thought that had something to do with OUT parameters.

No, not directly. The diffs needed for that are pretty simple though.

> - I assume that by using the get_call_result_type() PL/Java will not
> need any specific handling of functions returning OUT parameters since
> they are similar to functions returning a complex type.

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.

> - 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.

regards, tom lane