It's -2, see http://docs.oracle.com/javase/1.4.2/docs/api/constant-values.html#java.sql.Statement.SUCCESS_NO_INFO
2013/1/12 Dave Cramer <p...@fastcrypt.com> > Well my bet is the actual value of Statement.SUCCESS_NO_INFO is negative. > My understanding of the code is that it will not throw the exception unless > there is a real parse error. > > Dave > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > On Sat, Jan 12, 2013 at 5:06 AM, Péter Kovács < > peter.dunay.kov...@gmail.com> wrote: > >> But being designed for batch updates, is Statement.SUCCESS_NO_INFO >> appropriate in the context of plain updates? I think the value of >> Statement.SUCCESS_NO_INFO is supposed to be opaque. What if it happens to >> be 3, for example? Client code will think three rows have been affected. >> >> Conversely, if you plan to throw a batch update exception for all >> successful plain updates affecting too large amount of rows, client code is >> unlikely to be prepared to handle batch update exceptions for plain >> updates. (I feel there is also a more general usability problem with the >> JDBC API for batch updates expecting client code to expect exceptions to be >> thrown for successful executions. But I may be misunderstanding >> something...) >> >> Peter >> On Jan 12, 2013 10:41 AM, "Dave Cramer" <p...@fastcrypt.com> wrote: >> >>> Well since it returns an int and it's impossible to return > 2^32 in an >>> int then we will be returning Statement.SUCCESS_NO_INFO >>> >>> Dave >>> >>> Dave Cramer >>> >>> dave.cramer(at)credativ(dot)ca >>> http://www.credativ.ca >>> >>> >>> On Sat, Jan 12, 2013 at 4:27 AM, Péter Kovács < >>> peter.dunay.kov...@gmail.com> wrote: >>> >>>> I mean what value this method will return for an update statement >>>> affecting, say, five billion rows? But I may misunderstand something. >>>> On Jan 12, 2013 9:57 AM, "Dave Cramer" <p...@fastcrypt.com> wrote: >>>> >>>>> Peter, >>>>> >>>>> Can you be more specific about your concerns ? >>>>> >>>>> Dave >>>>> >>>>> Dave Cramer >>>>> >>>>> dave.cramer(at)credativ(dot)ca >>>>> http://www.credativ.ca >>>>> >>>>> >>>>> On Sat, Jan 12, 2013 at 3:25 AM, Péter Kovács < >>>>> peter.dunay.kov...@gmail.com> wrote: >>>>> >>>>>> And what about >>>>>> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()? >>>>>> >>>>>> P. >>>>>> On Jan 11, 2013 2:20 PM, "Dave Cramer" <p...@fastcrypt.com> wrote: >>>>>> >>>>>>> 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> wrote: >>>>>>> >>>>>>>> Dave Cramer <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 >>>>>>>> >>>>>>> >>>>>>> >>>>> >>> > -- Best regards, Vitalii Tymchyshyn
