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 <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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
