Thank you for your prompt reply. I was sure this topic was discussed here
I agree that setLong will solve my problem, as well as doing call to
"test_proc ( CAST(? AS bigint))".
My point here is that in such an intergation layer as JDBC is, strengthening
the type-checking will not lead to any good results for end-users of this
layer (software developers). It will force them to create an another
database abstraction sublayer.
Imagine tomorrow Postgres team would decide to expand the size of BIGINT
even more (ok, ok, create another HUGEINT/HUGESERIAL). What class in Java
should it be mapped to? java.math.BigDecimal? Is there any reason of using
BigDecimal in your application if you are NOT going to add, subtract,
multiply or take square root from it?
I think there must be support for String as input and output parameters for
the most of Postgres datatypes (numeric, date,..). Just my humble opinion.
> -----Original Message-----
> From: Roland Walter [mailto:rwa(at)mosaic-ag(dot)com]
> Sent: Wednesday, May 25, 2005 8:54 PM
> To: Sergey A. Sokolov
> Cc: pgsql-jdbc(at)postgresql(dot)org
> Subject: Re: [JDBC] BIGINT <-> java.lang.String auto cast
> Sergey A. Sokolov schrieb:
> > Hello all,
> > I would appreciate if JDBC development team consider my
> message as a
> > feature request for Postgres JDBC 8.xx drivers.
> > My issue is the following: in our application we use
> > for holding Identifier values of the database objects (portability,
> > extensibility, etc...), while PostgreSQL schema
> implementation have ID
> > fields as BIGINT's (or BIGSERIAL's) for most of the objects. We use
> > some stored procedures/functions in order to access and modify the
> > data and, certainly, have to pass ID values there from Java.
> > We use "PreparedStatement.setString(index, id);"-like statements in
> > Java for this kind of fields and everything works fine with JDBC
> > drivers version 7.4
> > -- I mean autocast works and stored procedure/function is
> being found
> > and called correctly.
> > When we moved to Postgres JDBC version 8.0, or 8.1dev -- we've ran
> > into the problem of getting exceptions like
> > org.postgresql.util.PSQLException: ERROR: function
> > varying) does not exist
> As I followed this mailinglist, this is a feature of version
> 8.x and you must use the setXXX-Method that fits the type of
> the parameter.
> In your case setLong(index, id).
> This feature was introduced to use real Prepared-Statements
> with the protocol v3 for client-server-communication of the database.
In response to
pgsql-jdbc by date
|Next:||From: hiuguis||Date: 2005-05-25 15:00:03|
|Subject: Re: Problem catching multiple values|
|Previous:||From: Roland Walter||Date: 2005-05-25 13:53:43|
|Subject: Re: BIGINT <-> java.lang.String auto cast|