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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server
Дата
Msg-id 15137.1179854963@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server  (Shachar Shemesh <shachar@shemesh.biz>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: like/ilike improvements
Следующее
От: "Guillaume Smet"
Дата:
Сообщение: Re: like/ilike improvements