From: | dmp <danap(at)ttc-cmc(dot)net> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Mapping Java BigDecimal |
Date: | 2010-01-19 14:59:31 |
Message-ID: | 4B55C8D3.7090907@ttc-cmc.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2010-01-19 16:00:59 | Re: Mapping Java BigDecimal |
Previous Message | Greg Stark | 2010-01-19 11:04:45 | Re: Mapping Java BigDecimal |