With a little bit of hacking, I figured out the internal representation that
PostGreSQL uses for its precision and scale values ... here's the diff for
the patch:
\postgresql-7.1\src\interfaces\jdbc\org\postgresql\jdbc2\ResultSetMetaData.j
ava
[root@TIMDA1 postgresbugfix]# diff ResultSetMetaData.java
ResultSetMetaData.java-original
288,293d287
< case Types.NUMERIC:
< Field f = getField(column);
< if(f != null)
< return ((0xFFFF0000)&f.mod)>>16;
< else
< return 0;
325,330d318
< case Types.NUMERIC:
< Field f = getField(column);
< if(f != null)
< return (((0x0000FFFF)&f.mod)-4);
< else
< return 0;
[root@TIMDA1 postgresbugfix]#
> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org]On Behalf Of David Esposito
> Sent: Wednesday, May 02, 2001 12:55 PM
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] getScale() and getPrecision()
>
>
> Is there a reason that getScale() and getPrecision() both return zero for
> NUMERIC fields? It seems like this shouldn't be the case. In the example
> fields below (generated by doing a \d on the table), it would
> seem like the
> getScale and Precision methods should return the numbers contained in the
> parentheses.
>
> Or at least that's how the docs seem to read and that's how Oracle does it
> too ... ;)
>
> catalog_item_id | numeric(11,0) | not null
> catalog_item_category_id | numeric(11,0) | not null
> catalog_item_manufacturer_no | character varying(20) |
> catalog_item_manufacturer_url | character varying(50) |
> catalog_item_retail_price | numeric(11,2) | not null
> catalog_item_member_price | numeric(11,2) | not null
> catalog_item_sellable | numeric(1,0) | not null
>
> -Dave
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
