From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, "Nathan M(dot) Davalos" <n(dot)davalos(at)sharedmarketing(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Function trunc() behaves in unexpected manner with different data types |
Date: | 2011-02-25 15:21:25 |
Message-ID: | 21330.1298647285@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> right -- in understand how floating point works -- but are you are
> saying that you are ok with the fact that (for example) a table with a
> floating point unique key could dump and not restore? more
> specifically, a binary dump would restore but a text dump would not.
pg_dump takes measures against that (see extra_float_digits).
> I think this is a problem with our implementation -- not all versions
> of 2183.68 as outputted from the server are the same internally.
It's an inherent property of float math. Yes, we could set the default
value of extra_float_digits high enough that distinct internal values
always had distinct text representations, but trust me, you would not
like it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2011-02-25 15:28:25 | Re: Function trunc() behaves in unexpected manner with different data types |
Previous Message | Merlin Moncure | 2011-02-25 14:46:29 | Re: Function trunc() behaves in unexpected manner with different data types |