Re: [JDBC] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception

One thought:

What about returning Statement.SUCCESS_NO_INFO as it says in
http://docs.oracle.com/javase/6/docs/api/java/sql/BatchUpdateException.html#getUpdateCounts%28%29
and
http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29

?

It seems better to report no number at all rather than a number
(INT_MAX) that is known to be wrong.

Dave Cramer schrieb:
> Ok, this is much more difficult than I thought.
>
> Turns out that there are at least two interfaces that expect an int
> not a long.
>
> BatchUpdateException
> executeBatch
>
> I'm thinking the only option here is to report INT_MAX as opposed to
> failing.
>
> Thoughts ?
>
> Dave
>
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Dave Cramer <pg(at)fastcrypt(dot)com <mailto:pg(at)fastcrypt(dot)com>> writes:
> > So an unsigned long won't fit inside a java long either, but
> hopefully it
> > will never be necessary. That would be a huge number of changes.
>
> I think we'll all be safely dead by the time anybody manages to
> process
> 2^63 rows in one PG command ;-). If you can widen the value from
> int to
> long on the Java side, that should be sufficient.
>
> regards, tom lane
>
>