From: | Sven Köhler <skoehler(at)upb(dot)de> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: BLOBs etc |
Date: | 2005-01-09 04:21:00 |
Message-ID: | crqbbj$rb2$1@sea.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
>> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2005-01-09 16:48:14 | Translation update: pt_BR and gettext-java broken? |
Previous Message | Thomas Hallgren | 2005-01-08 22:21:23 | Re: BLOBs etc |