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 по дате отправления: