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

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Lukas Eder <lukas(dot)eder(at)gmail(dot)com>, rsmogura <rsmogura(at)softperience(dot)eu>, pgsql-jdbc(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Date: 2011-02-17 12:15:36
Message-ID: 4D5D1168.2040209@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message rsmogura 2011-02-17 12:18:30 Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Previous Message Florian Pflug 2011-02-17 12:08:06 Re: Fwd: [JDBC] Weird issues when reading UDT from stored function

Browse pgsql-jdbc by date

  From Date Subject
Next Message rsmogura 2011-02-17 12:18:30 Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Previous Message Florian Pflug 2011-02-17 12:08:06 Re: Fwd: [JDBC] Weird issues when reading UDT from stored function