Re: How to avoid: 9.50184e+06

From: Ted Byers <r(dot)ted(dot)byers(at)rogers(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: How to avoid: 9.50184e+06
Date: 2007-09-28 15:28:50
Message-ID: 49556.86690.qm@web88307.mail.re4.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


--- Stefan Schwarzer <stefan(dot)schwarzer(at)grid(dot)unep(dot)ch>
wrote:

> Hi there,
>
> how can I avoid results like this: 9.50184e+06
>
> Instead it should return the "real" value, as
> 950184.
>
But 9.50184e+06 IS the real value! That is about nine
and a half million, not nine hundred and fifty
thousand, BTW. I do not see why you want the database
back end to divide the real number by ten and then
display the result as an integer.

I have not checked tbe behaviour of the functions
provided by Postgresql to convert numbers to strings,
but I would be surprised if a function suitable for
use in serializing a floating point number failed to
show 9.50184e+06 as "9.50184e+06"; to have it
automagically convert it to an integer would be
counter intuitive to me. Really, how a number is
displayed is properly in the domain of the client
application. If it is written in C, then you have
functions like printf, with all their glorious format
specifiers, to give you exactly what you want and
expect. And you have similar control with IO streams
in C++ and Java. ALL real programming languages
provide support for producing formatted output, and
give you absolute control over the format used.

Whether you are using a thin client or a thick client,
manipulating how floating point numbers really belongs
in the interface layer of the client.

If you want your numbers displayed as integers, then
you used the wrong type (as others have also
suggested). If the data really requires use of
floating point numbers, then use the libraries
provided by whatever language you're using to develop
your client to produce the format you want.

HTH

Ted

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Nico Sabbi 2007-09-28 15:37:38 row->ARRAY or row->table casting?
Previous Message Fernando De Pedro 2007-09-28 14:52:53 problemas zona horaria