Re: BLOBs etc
От
Kris Jurka
Тема
Re: BLOBs etc
Дата
Msg-id
Pine.BSO.4.56.0501062328590.14356@leary.csoft.net
Ответ на
Re: BLOBs etc (Sven Köhler)
Список
Дерево обсуждения
BLOBs etc Sven Köhler <skoehler@upb.de>
Re: BLOBs etc Oliver Jowett <oliver@opencloud.com>
Re: BLOBs etc Kris Jurka <books@ejurka.com>
Re: BLOBs etc Sven Köhler <skoehler@upb.de>
Re: BLOBs etc Kris Jurka <books@ejurka.com>
Re: BLOBs etc Sven Köhler <skoehler@upb.de>
Re: BLOBs etc Kris Jurka <books@ejurka.com>
Re: BLOBs etc Sven Köhler <skoehler@upb.de>
Re: BLOBs etc Kris Jurka <books@ejurka.com>
Re: BLOBs etc Sven Köhler <skoehler@upb.de>
Re: BLOBs etc Kris Jurka <books@ejurka.com>
Re: BLOBs etc Thomas Hallgren <thhal@mailblocks.com>
Re: BLOBs etc Oliver Jowett <oliver@opencloud.com>
Re: BLOBs etc Thomas Hallgren <thhal@mailblocks.com>
On Fri, 7 Jan 2005, [ISO-8859-15] Sven Köhler wrote: > > The JDBC driver doesn't know what the target table looks like. It must > > blindly send data and hope it matches. This is why the set methods can > > only work for one type while the get methods could work for both. > > Is this going to be improved? Either by using serverside prepared > statements or by changing the server's bahaviour somehow? > No, this was actually a design decision. It is possible to determine the expected data type in many cases, but the downside is that it requires a network roundtrip to the server. For simple statements this has the potential to nearly double execution time, so we don't want to do that. Could we perhaps do this for prepared statements we expect to reuse? We could, but then you've introduced an odd inconsistency where sometimes things will work and sometimes they won't. Kris Jurka
В списке pgsql-jdbc по дате отправления