>> I'm not clear what your advocating in concrete terms. A new pseudo
>> type "binary data" that could be used until it needs to convert it
>> into a concrete type? When does this conversion have to happen?
>
> Couldn't this be limited to the client/server protocol? There are 4
> cases that will fail today. If you attempt to:
>
> 1. stream lob data from the client for storage in a bytea.
> 2. send a bytea data "by value" for storage in a LOB.
> 3. read LOB data that is passed as a bytea.
> 4. read bytea data that is really a LOB.
>
> As you pointed out earlier, it should be possible to make the client
> handle cases #3 and #4 so what's left for the server is to deal with #1
> and #2. That doesn't sound like rocket science to me.
I see that i'm not alone :-)
I would already be satisfied, if case #2 would be handled by the server,
and #4 would be handled by the client. That would make the LOB ths most
compatible datatype. The difference between bytea and LOBs may be a bit
confusing sometimes, but well, i don't see a problem with semantics. The
way to access the binary data (with autocommit on or off) is a forced by
the column's datatype, and not by the Java-method which is called.