On Tue, 2010-08-31 at 14:13 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> >> You need extra_float_digits cranked up. Which pg_dump knows about.
>
> > I can't reproduce the problem with float4/8, but I still see a problem
> > with floating-point timestamps:
>
> Hmmm ... timestamp_out pays no attention to extra_float_digits, but just
> arbitrarily rounds off at six fractional digits. Maybe we should change
> that. Although I'm not certain it would result in any strong guarantees
> anyway, because of the extra arithmetic involved in timestamp I/O
> conversions. As you say, it's irrelevant for Alex's problem; and maybe
> it's not worth working on now that float timestamps are deprecated.
Agreed, it wouldn't be worth fixing if we can't really be sure that the
input/output functions are inverses. Also, the potential problem with
UNIQUE is pretty unlikely (both in terms of "why would you do that?" and
"you would have to be very unlucky").
It seems like it's mostly a problem for people using floating point
timestamps as a boundary, because you may expect the boundaries to line
up in a certain way. Anyone using floating-point timestamps with the
PERIOD data type, or anyone using the two-column "_start" and "_end"
representation is at risk. I think this is a pretty strong argument that
floating-point timestamps are broken for all but fairly simple
use-cases.
Regards,
Jeff Davis