Re: float8 auto truncation issue in ODBC v. PGSQL
От | Campbell, Greg |
---|---|
Тема | Re: float8 auto truncation issue in ODBC v. PGSQL |
Дата | |
Msg-id | 448F27E6.406@us.michelin.com обсуждение исходный текст |
Ответ на | Re: float8 auto truncation issue in ODBC v. PGSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-odbc |
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
Вложения
В списке pgsql-odbc по дате отправления: