I think I found the solution.

When I set this parameter on the pg10 client connection, the pg10 REAL
value format same as the pg83 value:

SET extra_float_digits = 0;

Interesting, because the default value is 0 in the postgresql.conf:
#extra_float_digits = 0                 # min -15, max 3

Do you have any ideas how can I format the miliseconds too?

Thx,
Csaba

2018-09-10 12:00 GMT+02:00 Peter J. Holzer <hjp-pg...@hjp.at>:

> On 2018-09-10 11:57:42 +0300, Achilleas Mantzios wrote:
> > On 10/09/2018 11:22, Csaba Ragasits wrote:
> >     Hello,
> >
> >     We would like to migrate our old databases to new postgres server,
> >     with the simple backup-restore process. The process run fine
> >     without errors but when we're  checking the source and the
> >     migrated datas as field level, we found the following differences:
> [...]
> >
> >     Field type: REAL
> >     pg93: 2.2
> >     pg10: 2.20000005
> >
> >
> > Those have to do with rounding. Precision for real is 6 decimal
> > digits. Your difference is on the 8-th digit.
>
> Nitpick: Precision is 24 binary digits which is *about* 6 decimal
> digits. The number which is actually stored (on both pg93 and pg10) is
> actually 2.2000000476837158203125 (1.00011001100110011001101 * 2^1 in
> binary). Apparently Pg9.3 rounds this to "2.2" on output while Pg10
> prints the more precise (but still not exact) "2.20000005".
>
> (I would argue that the Pg9.3 output is better, since it represents the
> same value in fewer digits, but always printing the minimum number of
> digits necessary is surprisingly difficult.)
>
>         hp
>
> --
>    _  | Peter J. Holzer    | we build much bigger, better disasters now
> |_|_) |                    | because we have much more sophisticated
> | |   | h...@hjp.at         | management tools.
> __/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
>

Reply via email to