Yes, that seems like a much better approach. I'm guessing SUCCESS_NO_INFO is < 0 and an int. I can't wait for the error reports (arguments)
Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Fri, Jan 11, 2013 at 10:32 AM, Stefan Reiser <s.rei...@tu-braunschweig.de > wrote: > 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<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<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 <t...@sss.pgh.pa.us <mailto: >> t...@sss.pgh.pa.us>> wrote: >> >> >> Dave Cramer <p...@fastcrypt.com <mailto:p...@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 >> >> >> >
