Re: BIGINT <-> java.lang.String auto cast

I have a patch that I haven't applied yet, but can that will allow you
to use setObject(n, obj,sqltype) and it will convert obj to the sqltype
requested as per the spec.

I have been holding back applying this patch but could apply it if this
will help.

Dave

Sergey A. Sokolov wrote:

>Hello Roland,
>
>Thank you for your prompt reply. I was sure this topic was discussed here
>many times.
>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.
>
>Sergey Sokolov
>
>
>
>>-----Original Message-----
>>From: Roland Walter [mailto:rwa@mosaic-ag.com]
>>Sent: Wednesday, May 25, 2005 8:54 PM
>>To: Sergey A. Sokolov
>>Cc: pgsql-jdbc@postgresql.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
>>>
>>>
>>java.lang.String
>>
>>
>>>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
>>>
>>>
>>proc_test(character
>>
>>
>>>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.
>>
>>Regards,
>>Roland.
>>
>>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>
>
>