Re: Mapping Java BigDecimal

Поиск
Список
Период
Сортировка
От dmp
Тема Re: Mapping Java BigDecimal
Дата
Msg-id 4B55C8D3.7090907@ttc-cmc.net
обсуждение исходный текст
Ответ на Re: Mapping Java BigDecimal  (Greg Stark <gsstark@mit.edu>)
Список pgsql-jdbc
Yesterday I indirectly, but did not completely demonstrate
the difference between the BigDecimal and Numeric data
types in the databases. My example indicated the precision
is carried and return in the default when no precision is given
for Numeric, but more importantly:

postgres=# CREATE TEMP TABLE test (x numeric, y numeric(19, 2));
CREATE TABLE
postgres=# INSERT INTO test VALUES ('3.48', '3.48');
INSERT 0 1
postgres=# INSERT INTO test VALUES ('0.056', '0.056');
INSERT 0 1
postgres=# SELECT SUM(x), SUM(y) FROM test;
  sum  | sum
-------+------
 3.536 | 3.54
(1 row)

As indicated PostgreSQL kept the precision and rounded for
the specified y column to the precision defined. The unspecified
precision column x just kept on adding precision decimal places.
If you chop either the x or y column decimal places you will
get the whole Integer 3. The same process in Oracle for the summing
with a BigDecimal data type I suspect most likely will return 4.
The BigDecimal is a BigInteger rounded to the specified precision.
Quite a difference creature than the Numeric(19, 2) in PostgreSQL,
which is real with rounding to the precision specified, not to the
nearest whole Integer.

Perhaps this whole mapping question should be put over to the
database forum for an appropriate answer to BigDecimal to what
in PostgreSQL.

danap.





В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Mapping Java BigDecimal
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: Mapping Java BigDecimal