Skip site navigation (1) Skip section navigation (2)

Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Sylvain Leroux <sl20(at)wanadoo(dot)fr>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject
Date: 2009-08-05 13:17:54
Message-ID: 4A798682.9080204@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Sylvain Leroux wrote:
> Hi,
> 
> and first of all, thanks for your answer.
> 
> Oliver Jowett a écrit :
>> Why NUMERIC instead of an integer type?
>>
>> Might as well make setBigInteger() private if you're not also going to
>> expose it on PGStatement (I don't think it needs to be exposed there)
> According to the JDK doc, java.math.BigInteger provides
> "arbitrary-precision integers".
> The closest match will be NUMERIC since it allows up to 1000 digits. As
> far as I know, the integer types have much narrower range.
> 
> *Or* could it be required to inspect the BigInteger in order to use the
> most appropriate type? But, I don't see any benefits here: it appears
> not to be a problem to send a NUMERIC value for an INTEGER column - as
> far as the value is in the supported range.

But there's no implicit cast from NUMERIC to integer types, is there?
(It'd lose precision)

> oliver=# CREATE OR REPLACE FUNCTION test_numeric(int4) RETURNS int4 AS 'SELECT $1' LANGUAGE SQL;
> CREATE FUNCTION
> oliver=# PREPARE s1(int4) AS SELECT test_numeric($1);
> PREPARE
> oliver=# PREPARE s2(numeric) AS SELECT test_numeric($1);
> ERROR:  function test_numeric(numeric) does not exist
> LINE 1: PREPARE s2(numeric) AS SELECT test_numeric($1);
>                                       ^
> HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
> 

So my concern with mapping Jython integer value -> BigInteger -> NUMERIC
is that you end up with a statement parameter that's not actually an
integer, and so "stmt.setObject(1,1234567899999)" will fail in cases
where you would expect an integer value to work.

Selecting a target type based on the magnitude of the parameter value
passed may work better; then at least you get obvious behavior for cases
where the value can fit in an integer.

-O

In response to

Responses

pgsql-jdbc by date

Next:From: JUNG, ChristianDate: 2009-08-05 15:53:17
Subject: PATCH: SET ROLE as connection parameter
Previous:From: Sylvain LerouxDate: 2009-08-05 13:16:33
Subject: Re: float4 or real in function parameter -> PSQLException: ERROR function in_test4(double precision) does not exist

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group