Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
| От | Dave Cramer |
|---|---|
| Тема | Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
| Дата | |
| Msg-id | CADK3HHLaQ96jMrf4RLRpseADdFOwD0DxOp9xF4C2OiEOBzmroA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [BUGS] BUG #7766: Running a DML statement that affects
more than 4 billion rows results in an exception
Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
| Список | pgsql-jdbc |
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
On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dave Cramer <pg@fastcrypt.com> writes:I think we'll all be safely dead by the time anybody manages to process
> 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.
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
В списке pgsql-jdbc по дате отправления: