On Mon, Jul 26, 2004 at 10:06:28PM -0400, [EMAIL PROTECTED] wrote:
> So what you are saying is that you should inconvenience 90% of your users
> to make sure they do something "right?"
I would say that was pretty solid reasoning. Exposing 10% of users to a
high data corruption risk just to get
Oliver Jowett wrote:
I suppose so. I'd point out that the NIO byteorder info is really just
an optimization hint -- the rest of the NIO API is byteorder agnostic,
regardless of what the native byteorder is.
The rest of the NIO API is not agnostic. A java.nio.ByteBuffer is big
endian by default
Thomas Hallgren wrote:
"Oliver Jowett" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
NIO is not present before JDK 1.4. The JDBC driver, at least, needs to
support earlier JVMs.
Clients only capable of network order (such as a Java 1.3 based JDBC driver)
must of course be supported st
"Oliver Jowett" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> NIO is not present before JDK 1.4. The JDBC driver, at least, needs to
> support earlier JVMs.
>
Clients only capable of network order (such as a Java 1.3 based JDBC driver)
must of course be supported still. No argument
Thomas Hallgren wrote:
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 byt
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.
> This actuall
> [EMAIL PROTECTED] writes:
>> Lastly, the vast majority of machines in use today are intel. Meaning
>> that
>> they are small endian. Except in a very rare circumstance, two machines
>> that would normally be able to communicate in native byte order, will
>> ALWAYS have to convert data.
>
> Quite
[EMAIL PROTECTED] wrote:
The only use case network byte order fixes is a BINARY COPY between
different machine types, but in doing that, it forces anyone trying to add
value to postgresql or create a utility that uses COPY to reimplement all
the data type handlers outside of the database, even if t
[EMAIL PROTECTED] writes:
> Lastly, the vast majority of machines in use today are intel. Meaning that
> they are small endian. Except in a very rare circumstance, two machines
> that would normally be able to communicate in native byte order, will
> ALWAYS have to convert data.
Quite honestly, th
OK, I wrote a utility for 7.3 that takes the output of a select command in
a Binary cursor and creates a binary "COPY" file.
The premise of the utility is to take the results of two or more selects
from external databases and create a single unified table.
Here are the issues:
In 7.3, COPY BINAR
10 matches
Mail list logo
