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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
