I've disassociated floats and exactness, that is floating point representations and exact matches do not
seem to go together. The idea was made more profound when I started looking into the multitude of options
in representing a float in 16, 32 or 64 bits. There are so many different ways to allocate bits for the
number, and bits for the exponent, leading to radically different precisions. Between a value on the
server and a value on the client a difference out in the 15th decimal place hardly seems surprising.
That float_extra_digits is a cool thing to know.
Tom Lane wrote:
> postgresql.org@tgice.com writes:
>
>>When I use my own ODBC SQL client to select the same value from my
>>Postgres 8.0 database, I get the same thing:
>> 1.0475000000000001
>
>
>>*However*, and here's the troubling part, when I select the exact same
>>value using psql (and I have reason to believe the same thing is going
>>on inside pl/pgsql functions), the value that comes out is:
>> 1.0475
>
>
> By default, the float8 output routine prints a digit or so less than it
> could, precisely to avoid that sort of unsightly result. You can fool
> with float_extra_digits (I think that's the right name, check the docs)
> if you need to adjust this behavior.
>
> This would only matter within a plpgsql function if you are doing
> something that forces the binary value to be converted to text. Which,
> if you're doing tense float computation, you probably don't want to have
> happen at all.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster