Re: Mapping Java BigDecimal - Mailing list pgsql-jdbc

From dmp
Subject Re: Mapping Java BigDecimal
Date
Msg-id 4B55C8D3.7090907@ttc-cmc.net
Whole thread Raw
In response to Re: Mapping Java BigDecimal  (Greg Stark <gsstark@mit.edu>)
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: Mapping Java BigDecimal
Next
From: Thomas Kellerer
Date:
Subject: Re: Mapping Java BigDecimal