Re: float output precision questions - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: float output precision questions
Date
Msg-id 20021030074903.C31345-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: float output precision questions  (Pedro Miguel Frazao Fernandes Ferreira <pfrazao@ualg.pt>)
List pgsql-hackers
On Wed, 30 Oct 2002, Pedro Miguel Frazao Fernandes Ferreira wrote:

> Stephan Szabo wrote:
> > On Tue, 29 Oct 2002, Peter Eisentraut wrote:
> >
> >
> >>Pedro Miguel Frazao Fernandes Ferreira writes:
> >>
> >>
> >>>Is there a way to set query output precision to maximum precision ?
> >>>For the type of application I mentioned this is crucial. People want to
> >>>get the 'same' numbers, from querys or dumps, as they inserted them.
> >>
> >
> > How do you define maximum precision and "same"?  With simple test programs
> > in C, using two digits more than DBL_DIG for printf specifier, it's easy
> > for me to find numbers that "change" decimal string representation in the
> > decimal representation -> double -> decimal representation conversion(*).
> > The final double you get from the second conversion should be the same as
> > the first, but is that what you need or do you need a stronger guarantee
> > than that?
>
> When I say "same" I am talking about having a number 'stored' in double
> format in some client, inserting it in PostgreSQL float8 field and get
> it to the client as it was before:
>
>    [Some client]  (insert)   [PostgreSQL]  (query)  [Some client]
> (double number a)-------->(float8 number)------->(double number b)
>
> "same" is so that a==b is true.
> With current float8 output this is not allways true.
>
> I believe this should allways be true for numbers which are originally
> stored in double format.

The problem is that there are two competing needs here.  One is the above,
the other other is that you get something that has the same decimal
representation (within the float's ability to store the number). Right now
the system does the latter since for most people, that seems to be the
guarantee they want.

This would probably make sense as an option, so why don't you look at the
past discussions and see if you can come up with a solution that keeps
everyone happy (and preferably implement it, but...) :)





pgsql-hackers by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: [GENERAL] Database replication... - Mission Critical DBMS's --
Next
From: Stephan Szabo
Date:
Subject: Re: Strange cost computation?