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

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