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