Re: BLOBs etc
От
Kris Jurka
Тема
Re: BLOBs etc
Дата
Msg-id
Pine.BSO.4.56.0501070029280.743@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: > But still the postgresql server could accept the data generated by the > JDBC-driver's "setBinaryStream()" even for oid columns. Isn't that the > missing piece to make set/getBinaryStream() methods work for oid columns? That would work, but it's not going to happen. Setting up and using a large object is completely different than just stashing data in a bytea field. Convincing the server to do simple conversions is difficult enough, getting it to do something of this magnitude is out of the question. > Is it known how other JDBC drivers handle this problems? The real problem here is that pg has two binary data types that work quite differently and each have significant strengths/weaknesses. Other databases don't have this predicament. If we only had one or one was clearly superior or they used a remotely similar API we'd be set. Kris Jurka
В списке pgsql-jdbc по дате отправления