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

Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Sylvain Leroux <sl20(at)wanadoo(dot)fr>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject
Date: 2009-08-11 13:50:25
Message-ID: 8312.1249998625@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-jdbc
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

In response to

pgsql-jdbc by date

Next:From: Vikas ZachariaDate: 2009-08-15 08:05:55
Subject: Connection btween Jdeveloper & postgresql 8.3
Previous:From: Kris JurkaDate: 2009-08-11 05:07:29
Subject: Re: Using BigInteger as argument to AbstractJdbc2Statement.setObject

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