On 18/02/11 01:08, Florian Pflug wrote:
>> Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could
theoreticallydo 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
whichparameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one
queryform that would handle all cases.
>
> Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the JDBC statement {call f(?,?)} either
translatesto
> 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
distinguishthese two cases?
Currently it always includes *all* parameters in the call, regardless of
the number of OUT parameters (as mentioned, it doesn't even know how
many OUT parameters there are at that point). As we discover OUT
parameters, we bind void types to them, and the server does the rest of
the heavy lifting. Something roughly equivalent to this:
> testdb=# PREPARE s1(void) AS SELECT * FROM p_enhance_address4($1); -- function has no IN parameters, one OUT
parameter
> PREPARE
> testdb=# EXECUTE s1(null);
> street | zip | city | country | since | code
> ------------------------+--------+-----------+---------+------------+------
> ("Parliament Hill",77) | NW31A9 | Hampstead | England | 1980-01-01 |
> (1 row)
Oliver
