Re: Binary Cursors, and the COPY command

On Mon, Jul 26, 2004 at 10:06:28PM -0400, pgsql(at)mohawksoft(dot)com 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 slightly better CPU performance on
I/O bound operations (think Amdahl's Law!) does not sound all that sensible
to me. Remember what happened to NT on the Alpha? Device driver writers
failed to use the portability macros for byte or 16-bit memory-mapped
hardware register accesses, exactly because it also worked without on x86.

This was one of the main reasons why they had to add 8-bit and 16-bit
loads and stores to the architecture! Similarly, lots of programs harbor
annoying, hard-to-find endianness bugs because little-endian byte order
happens to hide some typical pointer bugs.

> When you *really* think about it, by forcing a big endian byte order over
> machine dependent byte order, you are inconveniencing 90% of the users,
> but only helping the very small amount of people who run in mixed
> environments where the server is intel and the client is big endian.

I don't see this holding in situations where the user, the programmer, and
the systems manager are different (groups of) people. Users may want to
connect to different servers. Systems managers may want to replace servers.
In today's world even a non-programming user might recompile your
application on a big-endian machine. Applications may be running under
emulation, and people will prefer to run the database server natively.

All those scenarios may break the client-side application. The chance that
the mixed-endian scenario had never been tested would be close to those 90%.

> Few deployments will *ever* really have different endian-ness amongst
> their servers. 99% of all deployments will be the same or compatible
> hardware, and probably intel at that.

I'd like to add 2 points here:

1. Server architectures and client architectures are two very different
things. There are lots of SPARC, PA-RISC, MIPS, POWER, zSeries etc.
servers out there.

2. Even if both platforms are AMD or AMD-clones (we'll have to get used to
saying that as 64-bit becomes more popular), the number of situations where
this is _guaranteed_ as a part of the project definition will be much lower.

Remember, the programmer should generally support both the single-endian
and the big-endian scenario anyway. We might as well make sure that the
hardest is also the most widely tested.

Jeroen