You could always implement your own logical blob manager that implements blob IDs
and breaks blobs into BYTEA records of a particular (manageable) maximum size and associates
multiple BYTEA chunks with the blob id.
More work, but a least common denominator approach that should be portable to other systems as well.
Nicolas Modrzyk wrote:
I was following the conversation on blobs with interest.
c-jdbc supports Blobs and Binaries with Postgres.
At the moment though, given the number of different platforms we are
trying to support there is no streaming as such available.
But you can definitely stored and retrieve Blobs from your postgres
databases environment with redundancy.
Nicolas,
On Wed, 2003-09-10 at 15:32, Andreas Prohaska wrote:
Looking at the AbstractJdbc2Blob class I think that JDBC Blobs
internally
use LargeObjects. As I know, this was not the case in earlier versions
of the driver. Am I right?
This is for the PostgreSQL Large Objects, not the standard JDBC and SQL
BLOBs.
OK. If I got you right, the Postgres JDBC driver "simulates" the
java.sql.Blob
getBinaryStream() etc. methods by using LargeObject internally.
That seems to be a working solution for me. I just want to keep my
application's
database layer compatible using ordinary JDBC objects. I don't mind if
they are mapped to LargeObject internally. Actually that's even better
regarding
the streaming issues :-)
I assume that I can use this to read and write Blobs, not to delete them
since the LargeObject wouldn't be unlinked.
I'm not familiar with the JDBC driver source, and I would be glad if you
could
confirm this just one more time.
So far, I'm using LargeObjects and everything works fine, but I intend
to
use c-jdbc for db replication and would have to use JDBC blobs then.
We don't have them yet because PostgreSQL does not have them. But I
believe c-jdbc works with PostgreSQL so there must be a way around it.
It certainly works with Postgres, the only question is if it works with
blobs?
I'll try it out.
Thanks for your help,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
