Re: upgrading from 7.3.5 to 8.1.5 - Mailing list pgsql-novice

From Tom Lane
Subject Re: upgrading from 7.3.5 to 8.1.5
Date
Msg-id 25701.1167527384@sss.pgh.pa.us
Whole thread Raw
In response to upgrading from 7.3.5 to 8.1.5  (Frank Bax <fbax@sympatico.ca>)
Responses Re: upgrading from 7.3.5 to 8.1.5
List pgsql-novice
Frank Bax <fbax@sympatico.ca> writes:
> 1) select and pg_dump produce different results. Why does .06 change to
> .0601 and .07 to .0699?

It's actually the same values --- remember that float4 is only good to
a bit over six decimal digits anyway.  Post-7.3 versions of pg_dump set
"extra_float_digits" to provide a couple of guard digits in the output:

regression=# select 2006.18::real;
 float4
---------
 2006.18
(1 row)

regression=# set extra_float_digits TO 2;
SET
regression=# select 2006.18::real;
  float4
-----------
 2006.1801
(1 row)

On machines with properly-written floating point I/O, this ensures you
get back exactly the same float4 bit pattern you had stored before.
But it looks a bit funny, because the last digit is not "accurate"
in decimal terms.

> 2) age() changed from 7.3.5 to 8.1.5?

I see this in the 7.4.7 release notes:
    Make age(timestamptz) do calculation in local timezone not GMT
It looks like the examples you cite are crossing DST boundaries, so
the one-hour difference is correct.  Depending on what you are trying
to accomplish, you might wish to do the calculation in timestamp without
time zone.

            regards, tom lane

pgsql-novice by date:

Previous
From: Frank Bax
Date:
Subject: upgrading from 7.3.5 to 8.1.5
Next
From: Frank Bax
Date:
Subject: Re: upgrading from 7.3.5 to 8.1.5