Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function
От | Oliver Jowett |
---|---|
Тема | Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function |
Дата | |
Msg-id | 4D5C6876.7060805@opencloud.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Fwd: Weird issues when reading UDT from stored
function
Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function |
Список | pgsql-jdbc |
On 17/02/11 04:23, Tom Lane wrote: > Florian Pflug <fgp@phlo.org> writes: >> Hm, I've browsed through the code and it seems that the current behaviour >> was implemented on purpose. > > Yes, it's 100% intentional. The idea is to allow function authors to > use OUT-parameter notation (in particular, the convention of assigning > to a named variable to set the result) without forcing them into the > overhead of returning a record when all they want is to return a scalar. > So a single OUT parameter is *supposed* to work just like a function > that does "returns whatever" without any OUT parameters. > > Even if you think this was a bad choice, which I don't, it's far too > late to change it. 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. The current approach is to say "SELECT * FROM f(params) AS RESULT" which works in all cases *except* for the case where there is exactly one OUT parameter and it has a record/UDT type. Oliver
В списке pgsql-jdbc по дате отправления: