Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject

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.

Concerning the visibility of setBigInteger(), you're perfectly right: it
should be private [I must admit it was a (too) quick-and-dirty patch -
mostly a copy of setBigDecimal - sorry ;) ]

>
> Incidentally, the JDBC spec does provide a standard mapping from
> BigDecimal (not BigInteger) to NUMERIC.
You are right here too: I've double checked the JDBC documentation.
There's no mention of the BigInteger type - whereas the BigDecimal type
is supported.

I could have lived with that, but Jython maps values out of the Python
integer range to BigInteger. Not BigDecimal. Which is perfectly legitimate.
Moreover, I have done some tests with Groovy. It has somewhat the same
behavior and wraps literal integers that exceed the ''long'' range in a
BigInteger. So this could be definitively a concern for using prepared
statements with scripting languages.

As an attachment is a modified version of the patch - with setBigInteger
set private.

Sylvain

--
Website: http://www.chicoree.fr