From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Stefan Reiser <s(dot)reiser(at)tu-braunschweig(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, zelaine(at)amazon(dot)com, pgsql-bugs(at)postgresql(dot)org, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
Date: | 2013-01-11 15:38:05 |
Message-ID: | CADK3HHJ+yARXuNY5SxSkhFuvQfkyrHYTsOhss6uASJ4A49JHfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-jdbc |
Yes, that seems like a much better approach. I'm guessing SUCCESS_NO_INFO
is < 0 and an int. I can't wait for the error reports (arguments)
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Jan 11, 2013 at 10:32 AM, Stefan Reiser <s(dot)reiser(at)tu-braunschweig(dot)de
> wrote:
> 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<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<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 <tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:
>> tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>>
>>
>> Dave Cramer <pg(at)fastcrypt(dot)com <mailto: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
>>
>>
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2013-01-11 16:59:10 | Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
Previous Message | Stefan Reiser | 2013-01-11 15:32:35 | Re: [JDBC] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2013-01-11 16:59:10 | Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
Previous Message | Stefan Reiser | 2013-01-11 15:32:35 | Re: [JDBC] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |