Re: Fwd: [JDBC] Weird issues when reading UDT from stored function

On Feb17, 2011, at 11:15 , Oliver Jowett wrote:
> Florian Pflug wrote:
>> On Feb17, 2011, at 01:14 , Oliver Jowett wrote:
>>> Any suggestions about how the JDBC driver can express the query to get
>>> the behavior that it wants? Specifically, the driver wants to call a
>>> particular function with N OUT or INOUT parameters (and maybe some other
>>> IN parameters too) and get a resultset with N columns back.
>> There's no sane way to do that, I fear. You could of course look up the
>> function definition in the catalog before actually calling it, but with
>> overloading and polymorphic types finding the right pg_proc entry seems
>> awfully complex.
>> Your best option is probably to just document this caveat...
> 
> Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could theoretically do something different for 1 OUT vs. many OUT parameters.

Right, I had forgotten that JDBC must be told about OUT parameter with registerOutputType()

> The problem is that currently the translation of the JDBC "{ call }" escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases.

Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the JDBC statement {call f(?,?)} either translates to
  SELECT * FROM f($1)
or
  SELECT * FROM f($1, $2)
depending on whether one of the parameter is OUT. Without knowing the number of output parameters, how do you distinguish these two cases?

best regards,
Florian Pflug