Re: [BUGS] 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@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:

    Dave Cramer <pg@fastcrypt.com <mailto:pg@fastcrypt.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