How to avoid: 9.50184e+06
Hi there,
how can I avoid results like this: 9.50184e+06
Instead it should return the "real" value, as 950184.
Thanks for any hints!
Stef
____________________________________________________________________
Lean Back and Relax - Enjoy some Nature Photography:
http://photoblog.la-famille-schwarzer.de
Appetite for Global Data? UNEP GEO Data Portal:
http://geodata.grid.unep.ch
____________________________________________________________________
On 9/28/07, Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> wrote:
Hi there,
how can I avoid results like this: 9.50184e+06
Instead it should return the "real" value, as 950184.
The type 'real' in postgresql comes from the mathematical definition
of real, numbers that can be expressed as a fraction, or rational
numbers. In a practical sense, it is an alias for the binary floating
point type iirc.
In your case, it looks like you should be using the integer or the numeric type.
merlin
On Fri, Sep 28, 2007 at 02:08:18PM +0200, Stefan Schwarzer wrote:
how can I avoid results like this: 9.50184e+06
Instead it should return the "real" value, as 950184.
Presumably to_text would do what you want. Alternatively, perhaps you
intended your column to be type numeric?
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
On 9/28/07, Stefan Schwarzer <stefan.schwarzer@grid.unep.ch> wrote:
Hi there,
how can I avoid results like this: 9.50184e+06
Instead it should return the "real" value, as 950184.
Thanks for any hints!
Cast it to numeric:
select 9.50184e+06::real::numeric;
But know that you're losing accuracy if you're working with real / float types.
If you need all the parts of the number kept around, use numeric from the start.
--- Stefan Schwarzer <stefan.schwarzer@grid.unep.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