> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 12, 2004 1:00 PM
> To: Dann Corbit
> Cc: Bruce Momjian; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 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.
Depends on the compiler. The Intel C++ compiler can compile 80 bit
doubles.
> > 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.
As far as I know, name mangling only pertains to C++ compilers. And the
PostgreSQL project is entirely written in C.
> > 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.
Actually, I do want to use binary mode if possible. The data stream
will be more compact and that will be a stupendous advantage if I can
get it working right.
I am doing a port of the entire server code base to both the MS and
Intel compilers. Going pretty well so far.
---------------------------(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
