Andrew Dunstan wrote:
> >>> The problem I just encountered is that pg_dump uses
> >>> extra_float_digits=-3 for 9.0, while previous releases used '2'. I had
> >>> to do hack each server version to get a dump output that would match
> >>> without rounding errors --- it did eventually work and validated.
> >>>
> >
> >
> >> That sounds like a disaster waiting to happen. The server version is
> >> going to affect much more than just this behaviour, surely. Wouldn't it
> >> be better to provide a pg_dump option to provide the extra_float_digits
> >> setting?
> >>
> >
> > What disaster? That's only for test purposes, it has nothing to do with
> > actual data transfer.
> >
> >
> >
>
> Maybe I have misunderstood. How exactly is the server version being
> hacked here? I know it's only for testing, but it still seems to me that
> lying to a program as heavily version dependant as pg_dump is in general
> a bad idea.
The code in pg_dump 9.0 is:
/*
* If supported, set extra_float_digits so that we can dump float data
* exactly (given correctly implemented float I/O code, anyway)
*/
if (g_fout->remoteVersion >= 90000)
do_sql_command(g_conn, "SET extra_float_digits TO 3");
else if (g_fout->remoteVersion >= 70400)
--> do_sql_command(g_conn, "SET extra_float_digits TO 2");
The indicated line had to be changed to '3'. I did not change anything
else, and it was only done in my private CVS tree.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
