Re: [JDBC] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception

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 <pg(at)fastcrypt(dot)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(dot)dunay(dot)kovacs(at)gmail(dot)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" <pg(at)fastcrypt(dot)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(dot)dunay(dot)kovacs(at)gmail(dot)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" <pg(at)fastcrypt(dot)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(dot)dunay(dot)kovacs(at)gmail(dot)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" <pg(at)fastcrypt(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>>>>
>>>>>>>> Dave Cramer <pg(at)fastcrypt(dot)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