Re: 7.5 beta version

On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote:

> I do know of important differences in compilers in this regard. You can
> (for instance) have 80 bit floating point on one compiler using double
> but it is only 64 bits on another.

But in the case of x86 (among others) that's the in-register
representation, no? IIRC they are stored to memory as 64-bit doubles at
best.

> The point being that there is no such thing as a binary interface for
> alignments or data types that is defined by the C or C++ ANSI/ISO
> language standards. If there is another standard, I would like to hear
> about it.

That depends on the platform vendor. Which depending on the platform may
actually be whoever specified the CPU architecture and/or whoever supplied
the OS. As you say, compilers may deviate from it although in many cases
it would render them useless.

In this particular case, it would most likely be Microsoft as the dominant
{OS,compiler,everything else} vendor. I *think* (but I'm not sure) that
Microsoft set an ABI even at the C++ level (as Intel also did with the
Itanium, BTW), although it's more common to specify the C level only.

In C++, ABI compatibility is normally protected through a side effect of
name mangling. By maintaining different name mangling schemes for
different ABI conventions, compiler vendors ensure that object files will
refuse to link to other object files that adhere to different ABIs.

> Here is my puzzlement...
> If I compile a PostgreSQL database on some 64 bit machine, I should be
> able to access it from a 32 bit machine. For instance, I can access
> DB/2 on our 3090 or Rdb on our Alpha from a 32 bit workstation and I
> have no problems of this nature. Surely it is an issue with PostgreSQL
> that has been recognized before.

I would say yes, definitely! That part is not in question here, only the
linking-across-compilers part. But see below.

> If I change compilers or if I even completely change architectures it
> should not matter. The interface to the database should be architecture
> independent. Said another way:
> I should have no concerns about what sort of architecture the server is
> on or what compiler was used.

Unless you use the binary mode of data transfer perhaps; I think that's been
rationalized in 7.4 and is now portable. No idea what happens if you
convert tables written in an older version (say, 7.3) to 7.5 and then
read them from a wildly different platform than you wrote them from, but
that may be a bit far-fetched.

Jeroen