Re: prepared statement call fails
От | Markus Schaber |
---|---|
Тема | Re: prepared statement call fails |
Дата | |
Msg-id | 20041209112022.7de2c0b7@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответ на | Re: prepared statement call fails (Thomas Hallgren <thhal@mailblocks.com>) |
Список | pgsql-jdbc |
Hi, Thomas, On Mon, 06 Dec 2004 01:04:48 +0100 Thomas Hallgren <thhal@mailblocks.com> wrote: > Oliver Jowett wrote: > > > If you have some particular concerns about how the proposed SP syntax, > > whatever it is, is going to break the JDBC driver, by all means raise > > them.. but this seems like vague handwaving at the moment. > > I agree that abandoning the current support is a very bad idea. We all > have to live with it now. I was surprised to see that it was implemented > this way though. My guess is that it's uncommon. It's certanly doable > although you will need to dynamically support both mappings once the > real SP's arrive and also thoroughly explain some subtle differences in > how auto-commit works one way if the underlying code calls a function > and another way if it calls a stored procedure. The question is whether the new SP interface on the server will work for functions as well (as current functions are semantically a subset of what stored procedures can do). This would allow the drivers to always use the new way of calling. As I heard rumors that the stored procedures will be created by extending the current function capability, this sounds possible. So maybe we should try to influence the server hackers to go into this direction? Thanks, markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@logi-track.com | www.logi-track.com
В списке pgsql-jdbc по дате отправления: