Re: 7.5 beta version

From: "Dann Corbit" <DCorbit(at)connx(dot)com>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.5 beta version
Date: 2004-04-12 20:05:06
Message-ID: D90A5A6C612A39408103E6ECDD77B8299CA9D3@voyager.corporate.connx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:jtv(at)xs4all(dot)nl]
> Sent: Monday, April 12, 2004 1:00 PM
> To: Dann Corbit
> Cc: Bruce Momjian; pgsql-hackers(at)postgresql(dot)org
> 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.

Browse pgsql-hackers by date

  From Date Subject
Next Message Sean Chittenden 2004-04-12 20:05:55 Re: Information/schema hiding...
Previous Message pgsql 2004-04-12 20:02:16 Re: PostgreSQL configuration