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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shachar Shemesh <shachar(at)shemesh(dot)biz>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Greg Smith <gsmith(at)gregsmith(dot)com>, oledb-devel(at)pgfoundry(dot)org
Subject: Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server
Date: 2007-05-22 17:29:23
Message-ID: 15137.1179854963@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Shachar Shemesh <shachar(at)shemesh(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Smet 2007-05-22 17:38:48 Re: like/ilike improvements
Previous Message Tom Lane 2007-05-22 17:01:14 Re: like/ilike improvements