I agree with you practical points....I qualified my comments by
saying....theoretically speaking....
Cheers
Medi
On Nov 26, 2007 8:01 AM, Chris Browne <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] ("Medi Montaseri") writes:
> > But theoretically speaking, 32 or 64-bit ness of the application (ie the
> postmaster server) should not influence the data types offered by a
> particular DB
> > version. That is the semantics of data types and cpu-arch (register
> width, big endian, little endian, sparc, mips, x86), etc ) offered by a
> particular DB
> > version should be orthogonal.
> > A practical example is when I first begin my business on a Mac, then I
> move the database to a Sun and then on to a mainframe....
>
> That's well and fine, but the point is that when those (reasonably
> generic!) data types get compiled into code for a particular platform,
> with particular endianness and word size, how it is optimal to
> represent them will vary based on the characteristics of the platform.
>
> As a result, not only do you need different executable binaries each
> platform, but you also need different binary database structures on
> each platform.
>
> A conceptually mitigating factor should be that by the time you get
> around to changing platforms, there will likely be a Newer, Better,
> Major PostgreSQL version available. So you should be considering
> doing a migration from "old, slower, inferior version on the inferior
> platform" to the "better, stronger, faster version on the superior
> platform." With THAT context, the need to run initdb is further
> "given."
> --
> output = ("cbbrowne" "@" "linuxdatabases.info")
> http://www3.sympatico.ca/cbbrowne/x.html
> "Have you noticed that, when we were young, we were told that
> `everybody else is doing it' was a really stupid reason to do
> something, but now it's the standard reason for picking a particular
> software package?" -- Barry Gehm
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
