Re: ResultSet getString() result differs in 8.3 jdbc (compared to 8.1), with "real" type
От | Guillaume Cottenceau |
---|---|
Тема | Re: ResultSet getString() result differs in 8.3 jdbc (compared to 8.1), with "real" type |
Дата | |
Msg-id | 87y6szvdrb.fsf@meuh.mnc.lan обсуждение исходный текст |
Ответ на | ResultSet getString() result differs in 8.3 jdbc (compared to 8.1), with "real" type (Tanel <tanel.ehrenpreis@finestmedia.ee>) |
Ответы |
Re: ResultSet getString() result differs in 8.3 jdbc
(compared to 8.1), with "real" type
|
Список | pgsql-jdbc |
Tanel <tanel.ehrenpreis 'at' finestmedia.ee> writes: > Hi, > > I made some searches also, however found nothing exactly related to this > problem. We just shifted from using 8.1 driver to 8.3 however seems that 8.3 > driver handles differently Postgresql floating type values, when using > org.postgresql.jdbc2.AbstractJdbc2ResultSet.java getString() on them ? > For example, when there is "real" type value 20.7 in database and we try to > get it through getString() then old 8.1 driver returns nicely 20.7, but new > 8.3 driver is returning something like 20.700001. Wanting to manipulate precise decimal values with float or double datatypes is bound to fail, because the binary representation of values make it impossible - it holds the mantissa and the exponent, so some rounding must happen. The "display" will depend on rounding and so forth. 20.7 doesn't exist "as such" in the computer, when using float or double datatypes. If you want to manipulate precise decimal numbers, use the SQL NUMERIC data type (BigDecimal in java); or else, you can always use "fixed point" numbers, e.g. if you need a monetary value you may store cent values as an integer (2070 in database to represent $20.7) and shift by 100 only for user interfacing. Beside, getString() on a floating type value is just wrong, but you guessed it already! :) -- Guillaume Cottenceau
В списке pgsql-jdbc по дате отправления: