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
> 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
> the
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ác
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
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
wrote:
> I mean what value this method will retu
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" wrote:
> Peter,
>
> Can you be more specific about your concerns ?
>
> Dave
>
> Dave Cramer
>
> dave.cramer(at)credativ(do
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
wrote:
> And what about
> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()?
>
> P.
> On
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" 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.
>
> BatchUpda
Good points to both. Thank you both for reviewing.
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Jan 11, 2013 at 12:36 PM, Stefan Reiser wrote:
> Kris Jurka schrieb:
>
>
>> On Fri, 11 Jan 2013, Dave Cramer wrote:
>>
>> Ok, I've pushed this fix into master
>
Kris Jurka schrieb:
On Fri, 11 Jan 2013, Dave Cramer wrote:
Ok, I've pushed this fix into master
You've made any failure to parse the affected row count return
SUCCESS_NO_INFO. Shouldn't you change the integer parsing to a long
parsing and only modify the response if the value is > INT_MAX
On Fri, 11 Jan 2013, Dave Cramer wrote:
> Ok, I've pushed this fix into master
>
You've made any failure to parse the affected row count return
SUCCESS_NO_INFO. Shouldn't you change the integer parsing to a long
parsing and only modify the response if the value is > INT_MAX while still
thr
On Fri, 11 Jan 2013, Stefan Reiser wrote:
> 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
> and
> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29
Ok, I've pushed this fix into master
On Fri, Jan 11, 2013 at 10:38 AM, Dave Cramer wrote:
> SUCCESS_NO_INFO
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
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 wrote:
> One thought:
>
> What ab
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
and
http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29
?
It seems better to report no numb
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
Dave Cramer 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 f
Thanks Tom.
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.
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Dec 21, 2012 at 11:47 AM, Tom Lane wrote:
> zela...@amazon.c
zela...@amazon.com writes:
> The following bug has been logged on the website:
> Bug reference: 7766
> Logged by: Zelaine Fong
> Email address: zela...@amazon.com
> PostgreSQL version: 8.4.0
> Operating system: Linux
> Description:
> The updateCount field in the Result
The following bug has been logged on the website:
Bug reference: 7766
Logged by: Zelaine Fong
Email address: zela...@amazon.com
PostgreSQL version: 8.4.0
Operating system: Linux
Description:
The updateCount field in the ResultHandler interface in Java is defined as
an
19 matches
Mail list logo
