Re: float8 auto truncation issue in ODBC v. PGSQL

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(dot)org(at)tgice(dot)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