From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shachar Shemesh <shachar(at)shemesh(dot)biz> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Julian Heeb <heebj2000(at)yahoo(dot)de>, oledb-devel(at)pgfoundry(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server |
Date: | 2007-05-19 21:22:18 |
Message-ID: | 18440.1179609738@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:
>> Binary format has other goals that are not always compatible with 100%
>> platform independence --- that's unfortunate, sure, but it's reality.
>>
> Maybe the misunderstanding is mine. What are the goals for the binary
> format?
Well, the one that I'm concerned about at the moment is that dump/reload
using COPY BINARY ought to be 100% guaranteed to reproduce the original
datum.
Obviously, if you are transporting the dump across platforms then that
may be an impossibility. In that case you use a text dump and accept
that you get an approximation. But there should be a way to ensure that
you can have a lossless dump of whatever strange FP format your server
may use, as long as you are restoring onto a similar machine.
If there is a guaranteed-reversible transform between the ARM FP format
and IEEE format, then I'd be interested in hacking things the way you
suggest --- but what I suspect is that such a conversion must lose
either range or precision. There are only so many bits in a double.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-05-19 21:36:07 | Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server |
Previous Message | Shachar Shemesh | 2007-05-19 21:20:18 | Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server |