Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject

Kris Jurka <books(at)ejurka(dot)com> writes:
> On Thu, 6 Aug 2009, Sylvain Leroux wrote:
>> That's what I have done now: setBigInteger will choose the narrowest integer
>> representation. NUMERIC will still be used when no integer type is wide
>> enough to hold the value.

> I don't think this is a great idea. Changing behavior based on the value
> of the parameter will just lead to unpredictable behavior as the size
> boundaries are crossed.

For what it's worth, if you type a bare integer constant in a SQL
command, the backend will take it to be int4, int8, or numeric depending
on size. It's been that way for a long time and we've had few
complaints, in part because the set of implicit casts is designed
expecting that behavior. So I'm not sure that mirroring that behavior
on the JDBC side is a bad thing.

(However, if the proposed patch is also mixing int2 into the picture,
that *would* be a bad thing. Stick to int4 or larger.)

> 1) Always map BigInteger -> numeric.

This would break a lot of things. The backend's implicit casts are
designed to upcast int to numeric when context demands, but not the
reverse.

regards, tom lane