Re: regression failure on master with --disable-integer-datetimes

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Tue, 2014-05-06 at 14:48 -0400, Tom Lane wrote:
>> Hm. As the test stands, it requires a float-timestamps implementation
>> to store a value of 3600000610.000001 seconds, which is 16 decimal digits

> The test value has 1e9 hours, which is 3.6e12 seconds, plus 6 more
> digits for microseconds is 18 decimal digits. If, as you say, 15 digits
> can be reliably extracted from a double, then we need to cut three zeros
> (which matches my simple test of just removing zeros until it achieves
> the microsecond precision).

Um. I fat-fingered the math somehow ... I think I might've
copied-and-pasted from your modified test rather than the original.
But the bad news there is that you have too: 3.6e12 has got 13
digits to the left of the decimal point, leaving only 2 that could
be reliably extracted to the right. The correct math, if I've not
messed up again, is that this is the seconds value that the test
is trying to store:

regression=# select 1000000000.0*3600 + 10*60 + 10.000001;
?column?
----------------------
3600000000610.000001
(1 row)

which cannot be reproduced by float8:

regression=# select '3600000000610.000001'::float8;
float8
---------------
3600000000610
(1 row)

If we trim digits to the left of the decimal point, we need to
get rid of 4 not 3:

regression=# select '360000000610.000001'::float8;
float8
--------------
360000000610
(1 row)

regression=# select '36000000610.000001'::float8;
float8
-------------
36000000610
(1 row)

regression=# select '3600000610.000001'::float8;
float8
------------
3600000610
(1 row)

regression=# select '360000610.000001'::float8;
float8
------------------
360000610.000001
(1 row)

If we instead trim digits at the right, we have to go down to just 2,
at least on my Linux/x86_64 platform:

regression=# select '3600000000610.001'::float8;
float8
---------------
3600000000610
(1 row)

regression=# select '3600000000610.01'::float8;
float8
------------------
3600000000610.01
(1 row)

which squares with the expectation that you get between 15 and 16
decimal digits of precision from a float8.

In short, your revised test might work for you but I think we'd
need to drop another zero to have much confidence of it working
everywhere.

regards, tom lane