Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server
Date
Msg-id 15137.1179854963@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server  (Shachar Shemesh <shachar@shemesh.biz>)
List pgsql-hackers
Shachar Shemesh <shachar@shemesh.biz> writes:
> Tom Lane wrote:
>> I would concur with a patch that ensures that this is what happens
>> on the different ARM variants ... though I'll still be interested
>> to see how you make that happen given the rather poor visibility
>> into which model and endianness we are running on.
>> 
> You do it semantically. Attached is the outline for the code (I can form
> a patch only after we agree where it should go)

Cross-compile situations make life interesting.

[ hold your nose before reading further... ]

After studying how AC_C_BIGENDIAN does it, I propose that the best
answer might be to compile a test program that contains carefully-chosen
"double" constants, then grep the object file for the expected patterns.
This works as long as the compiler knows what format it's supposed to
emit (and if it doesn't, lots of other stuff will fall over).

The only alternative that would work reliably is to run the test once
when the result is first needed, which is kind of unfortunate because
it involves continuing runtime overhead (at least a "switch" on every
conversion).  We in fact did things that way for integer endianness
awhile back, but since we are now depending on AC_C_BIGENDIAN to get
it right, I'd feel more comfortable using a similar solution for float
endianness.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: like/ilike improvements
Next
From: "Guillaume Smet"
Date:
Subject: Re: like/ilike improvements