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 >>>>>>> >>>>>> >>>>>> >>>> >>
