Aaron Mulder wrote:
> On Tue, 22 Oct 2002, Barry Lind wrote:
>
>>That is correct. The FE/BE protocol sends the data back and forth as
>>strings for all the data types. The only exception to this is if you
>>are using a 'binary cursor' inwhich case the data is sent in binary,
>>(however the byte order is platform dependent, which makes it a pain to
>>use binary cursors).
>
>
> I think it would be less of a pain to deal with byte
> order/endianness than to constantly decode text into numbers. I mean,
> we'd use one routine to read all ints/floats/etc., and it's not hard to
> have a flag for whether to read abcd or dcba before we stuff it into an
> int/float/whatever. Java even has the methods to do this (see DataInput
> JavaDoc, Float.intBitsToFloat, etc.) All we need is some indicator of the
> native byte order of the server, which could be achieved by sending a
> single well-known number in the connection process (you know, the
> byte-level analog of "did the server report version 7.3 or 3.7?").
> Truly, one flag for endianness vs creating extra objects for every
> numeric value ever read from the server, and getting bugs like can't read
> "" as an integer? Which is really the pain?
>
> Not that you probably wanted me to agitate for architecture
> changes during the beta process... :)
There really isn't anything that can be done in the jdbc driver until a
change occurs in the FE/BE protocol. I agree that dealing with the
byte-order isn't too difficult (I actually do it in my code where I do
use binary cursors). But there are other issues as well, the least of
which is knowing the binary representation of each datatype (and types
like Date in 7.3 have two different formats depending on configure time
switches). It can get ugly :-)
thanks,
--Barry
PS. When I say binary cursor, I am talking explicitly about the sql
statement: declare binary cursor foo as select ...
All other sql statements are handled as strings.
