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 | 6e4f051fab6a5b06c7edc76c2a6466de@mail.softperience.eu обсуждение исходный текст |
Ответ на | Re: Fwd: [JDBC] Weird issues when reading UDT from stored function (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
|
Список | pgsql-hackers |
Yes new node should be created and added for 8.x and 9.x releases... On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote: > 2011/2/17 Florian Pflug <fgp@phlo.org>: >> On Feb17, 2011, at 10:30 , rsmogura wrote: >>> When JDBC driver will detect if procedure call statement is >>> created. >>> 1. Determine procedure oid - how? procedures may have not qualified >>> name. Is any function on backend that will deal with schema search >>> path? You may need to pass procedure parameters or at least types? or >>> we need to mirror backend code to Java? >> >> That change of getting this correct without help from the backend is >> exactly zero. (Hint: You need to consider overloaded functions and >> implicit casts of parameters...) >> > > There is only one way - implementation of CALL statement. Any > emulation on JDBC level is just way to hell. Now, we have to say - > PostgreSQL doesn't support a CALL statement, support only functions - > and everybody has to use a different pattern than in other databases. > Any emulation on JDBC means, it will be slowly, it will be > unpredictable. > > Regards > > Pavel Stehule > > >> best regards, >> Florian Pflug >> >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers >>
В списке pgsql-hackers по дате отправления: