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

Radosław Smogura <rsmogura@softperience.eu>

From: rsmogura <rsmogura@softperience.eu>
To: Oliver Jowett <oliver@opencloud.com>
Cc: Florian Pflug <fgp@phlo.org>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Lukas Eder <lukas.eder@gmail.com>, <pgsql-jdbc@postgresql.org>, <pgsql-hackers@postgresql.org>
Date: 2011-02-17T10:18:17Z
Lists: pgsql-hackers
 Yes, but driver checks number of declared out parameters and number of 
 resulted parameters (even check types of those), to prevent programming 
 errors.

 On Thu, 17 Feb 2011 23:15:07 +1300, 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.
>
> 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.
>
> Oliver