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
