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 по дате отправления
От: Sven Köhler
Дата:
Сообщение: Re: BLOBs etc
От: solar solar
Дата:
Сообщение: unsubscribe
FAQ