Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
От | rsmogura |
---|---|
Тема | Re: Fwd: [JDBC] Weird issues when reading UDT from stored function |
Дата | |
Msg-id | befa3498579f3abcc3d1e2e2b8579700@mail.softperience.eu обсуждение исходный текст |
Ответ на | Re: Fwd: [JDBC] Weird issues when reading UDT from stored function (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Fwd: [JDBC] Weird issues when reading UDT from stored
function
|
Список | pgsql-hackers |
Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. On Thu, 17 Feb 2011 23:15:07 +1300, 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. > > 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. > > Oliver
В списке pgsql-hackers по дате отправления: