Re: float8 auto truncation issue in ODBC v. PGSQL

["Campbell, Greg" <greg(dot)campbell(at)us(dot)michelin(dot)com>]

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
begin:vcard
fn:Greg Campbell
n:Campbell;Greg
org:Michelin North America - US5 Lexington;ENG-ASE
email;internet:greg(dot)campbell(at)us(dot)michelin(dot)com
title:ASE Systems Engineer
tel;work:803-951-5561/x75561
x-mozilla-html:FALSE
version:2.1
end:vcard