> Maybe the solution would be the subtype. As I read here:
> http://www.mers.com/INPRISE/FAQ/2842.HTML Maybe BLOBs with subtype 2
> should be treated as BLOB and subtype 0 and subtype1 should be
> treated as BINARY. This means when a Blob is subtype 2 it should
> not accept getBytes, setBytes, getString, setString and it should
> return a Blob with

I'm not sure about subtype 2, I never met it before. According to
Firebird docs, subtype < 0 is a user-defined type of blob, >= 0 -
reserved by a system (0 - binary data, 1 - text data).

> This is bit offtopic, but: when Sun introduced Blobs and Clobs in
> JDBC 2.1 they provided no way to update or a set a blob. There was
> only getBinaryStream. The only way to change data in a Blob was
> vendor-specific, you can not create a "Blob" object. Although JDBC
> 3.0 introduced new features for updating Blobs, I believe it
> suffers from the same problem. Although the new API (with
> setBinaryStream and setBytes)is much more useable when using
> updatable resultsets.

The main reason, why I would like to have Blob (sometimes) is that
when the content is really big, and I am not interested in the whole
chunk, but only in a small part, I still have the possibility (in
theory, not implemented yet) to fetch only necessary part of it.
Firebird API provides such functionality by allowing to fetch only
specific BLOB segment.

When using getBytes() or getBinaryStream(), you do not have such
possibility.

> In my eyes this is the historic reason for which other JDBC drivers
> does handle even the BLOB fields in the database as binary fields,
> because this it is much convinient to create a byte[] or String
> object rather than to create a FBBlobField, a PGSqlBlob or a Blob
> (in MySQL driver).

Yes, if you are working with the content as an atomic chunk of data.
No, if you go forth and backward looking for something. Then Blob is
more useful.

> One more little thought about the blob concept in JDBC:
>
> JDBC API says about Blob:
>
> (skipped)
>
> Actually I can't tell that I really understand why Sun created the
> Blob interface, but I suppose it is a helper for those databases
> that can operate on a BLOB field on the server with a LOCATOR
> object (like DB/2)

Well... this is the case of Firebird as well. BLOB content is stored
separately in the database, while the id of the BLOB is stored within
the row. You have to use different API to access the BLOB fields than
other fields. Same applies to ARRAY type.

But I agree that BINARY (or LONGVARBINARY) must be supported. My
suggestion is the following:
- if the subtype is 0 or 1 - this is LONGVARBINARY type;
- if the subtype is < 0 - this is a BLOB type.

Any objections?