Re: pg_upgrade and extra_float_digits

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >>
> >> 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.
> >
> >
>
> Oh, I see. It is pg_dump that you hacked. That wasn't clear to me from
> what you first said.
>
> But do earlier server versions accept a value of 3? The 8.4 docs say
> "The value can be set as high as 2".

That is the other thing I had to hack --- the 8.4 backend version had to
be changed to accept '3'. The good thing is this has to be done only
once --- once I have the dump file, I can use it in testing repeatedly
because 8.4 does not change.

Eventually the idea would be to have the build farm run such tests (with
a properly created dump file) so we can learn quickly if the backend
data format is changed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com