Oliver Jowett wrote:
> This is not true if you happen to be using Java on the client side,
> which has no idea (unless you grot around in the guts of the JVM) what
> the native byte order is.
>
The method java.nio.ByteOrder.nativeOrder() will tell you what the native byte order is.
NIO is not present before JDK 1.4. The JDBC driver, at least, needs to support earlier JVMs.
> This actually means that Java clients have the
> opposite problem -- it's a lot of work to try to use the 7.3-style
> binary formats.
>
The commonly used java.io.DataInput will always use network order but it's easy enough to read/write little endian using the java.nio and java.nio.channel packages.
That's no use if you don't know the endianness of the data you're receiving (which is what happens under <= 7.3 -- the data followed the server's byte ordering)
The problem with using native byte orderings is not the byte ordering itself, but that the order is unpredictable -- at best, you have to implement code to handle both orders, and at worst you have to just take a guess and hope you were right..
-O
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
