sgwood wrote:
Check out
http://doc.postgresintl.com/jdbc/ch08.html. There are two schemes for BLOBs in Postgres. Hibernate is using the BYTEA approach.
In looking at the details of the OID approach, it seems there is a lot more work needed to use the Postgres JDBC API to handle deletes and other transaction integrity issues, above using setBLOB and getBLOB.
Check out
http://archives.postgresql.org/pgsql-jdbc/2003-09/msg00105.php. It says that the JDBC driver does not really support SQL LOBs yet. The v7.5 driver is in development now, and will deal with LOBs properly.
To sum up my ramblings, I'd say they we should wait for the JDBC driver to do LOBs properly before changing Hibernate.
Sherman
Thanks for the links. Unfortunately, the BYTEA column type does not work with BlobType. I can save new objects (using Hibernate.createBlob()) but retrieving the objects results in an error ("Bad integer [content]"). The underlying ResultSet.getBlob() (called from BlobType) just doesn't work on BYTEA--getBinaryStream would probably work, though. (In this case BlobType's setBinaryStream call is a feature. :-))
Adding "?compatible=7.1" to the JDBC URL makes the insertion break instead ("ERROR: column "blob" is of type BYTEA but expression is of type integer").
Of course I could just change the column to a byte[] which works fine with BYTEA. But then you lose streaming, i.e., the whole binary content is pulled into memory at once. That isn't practical for large files, especially since 99% of the time we just want to pipe the LOB's InputStream directly to the servlet response's OutputStream without any processing.
Is there a better way to handle streaming binary data in PostgreSQL from Hibernate? There are obvious problems with OIDs (deletion is a biggie) but it seems oh-so-close to the way things are supposed to work.