| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Marco Colombo <pgsql(at)esiway(dot)net> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Multiline plpython procedure |
| Date: | 2005-01-21 16:52:37 |
| Message-ID: | 20050121165237.GA19792@wolff.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Jan 21, 2005 at 12:02:09 +0100,
Marco Colombo <pgsql(at)esiway(dot)net> wrote:
> On Fri, 21 Jan 2005, Greg Stark wrote:
>
> Anyway, think of floats. If you want do to FP maths fast, you need to use
> the native format supported by the CPU. When you dump, you get a text
> form of the FP number, and when you restore on a different platform you
> may get a _different_ number. And you have to live with it. Kiss goodbye
> to your "indentical database".
If you are going to another system that uses the same floating point
representation, you should get the same number. pg_dump writes out
enough digits that the exact number can be recovered when the dump
has been reloaded. This has been the case since 7.3.
If you move the data to a machine with a different floating point
representation you might get a different number even if the original number
could be represented exactly in the new representation.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruno Almeida do Lago | 2005-01-21 17:23:47 | Re: Best Linux Distribution |
| Previous Message | Jackson Pauls | 2005-01-21 16:39:32 | Re: connecting with a 8.0.0 client with ssl |