On Tue, 4 Mar 2008, Chris Gamache wrote:
> I was having a problem with JDBC expecting a DOUBLE from a PostgreSQL
> function which returnes "money" ... My first inclination was to return
> an OTHER, but PgJDBC balks that it expects java.sql.Types=8 (DOUBLE)
> but I set it to 1111 (OTHER) ... There was (seemingly) no way around
> that.
Someone else was just complainging about this recently:
http://archives.postgresql.org/pgsql-jdbc/2008-02/msg00202.php
> So, I decided to attack the root of the problem: PostgreSQL is
> returning "1,234.00" when it is executing the function that returns
> money and JDBC won't budge on it's expectation that it should be
> DOUBLE. The comma in the return string is confusing
> Double.parseDouble, so I filter out the commas before parseDouble is
> called. My hack got me over the hump, but it makes me uneasy to apply
> this patch to a codebase that I am not intimately familiar with. Can
> you propose a different way around this problem, a more complete
> patch, or the blessing that this will not adversely affect the normal
> function of the driver?
That's one approach, but you'd also have to apply it to other getXXX
methods if you really wanted to be able to treat money as a numeric type.
On the previous thread I was advocating taking this special case code out
of the common path instead of adding more. That seemed to be your first
inclination as well (wanting to get back Types.OTHER).
> s = s.replace(",",""); //filter out the commas
>
Your actual implementation is using a JDK 1.5 method while the driver
(probably unnecessarily) supports back to 1.2. So this may work for your
environment, but isn't a general solution. Other than that it looks fine
as long as you aren't concerned that values like "1,,,,,0" will no be
considered valid doubles.
Kris Jurka