Re: Fwd: [JDBC] Weird issues when reading UDT from stored function - Mailing list pgsql-hackers

From rsmogura
Subject Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Date
Msg-id befa3498579f3abcc3d1e2e2b8579700@mail.softperience.eu
Whole thread Raw
In response to Re: Fwd: [JDBC] Weird issues when reading UDT from stored function  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: Fwd: [JDBC] Weird issues when reading UDT from stored function  (Oliver Jowett <oliver@opencloud.com>)
List 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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Next
From: Jesper Krogh
Date:
Subject: Re: tsearch Parser Hacking