SEO

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.

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?

From org.postgresql.jdbc2.AbstractJdbc2ResultSet:

public static double toDouble(String s) throws SQLException
{
if (s != null)
{
try
{
s = s.trim();
s = s.replace(",",""); //filter out the commas
return Double.parseDouble(s);
}
catch (NumberFormatException e)
{
throw new PSQLException(GT.tr("Bad value for type
{0} : {1}", new Object[]{"double",s}),

PSQLState.NUMERIC_VALUE_OUT_OF_RANGE);
}
}
return 0; // SQL NULL
}

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...2/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

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_www...tra=pgsql-jdbc