On 10/02/2012 01:47 AM, the6campbells wrote:
> The test case can be shown with one table that contains a column for
> each supported Postgres type that maps to ISO-SQL or one table per type.
> This example compares an integer and a precise numeric type.
OK, so your issue is that PgJDBC reports zero scale and precision for
numerics as results when the numeric didn't come directly from a column
with defined scale and precision. Right?
If so, this has nothing to do with integer combinations, it's *any*
operation on numeric. It isn't a JDBC driver issue as such, it's the
behaviour of the underlying PostgreSQL backend.
Witness:
regress=# CREATE TABLE plain AS SELECT NUMERIC(6,4) '12.345678' ;
SELECT 1
regress=# CREATE TABLE modified AS SELECT ABS(NUMERIC(6,4) '12.345678') ;
SELECT 1
regress=# \d plain
Table "public.plain"
Column | Type | Modifiers
---------+--------------+-----------
numeric | numeric(6,4) |
regress=# \d modified
Table "public.modified"
Column | Type | Modifiers
--------+---------+-----------
abs | numeric |
As such there isn't tons the JDBC driver can do about it. The scale and
precision aren't preserved in results, so the JDBC driver has no way to
obtain them.
Would it be better if PgJDBC reported these numerics as having the
maximum supported size?
--
Craig Ringer