Re: JDBC gripe list (the autocommit subthread)

> Well in the postgresql world every statement is a transaction.

I agree with that. But a batch with autocommit=true is "many" statements, as per the doc.

> That being said  the concept of batch processing in postgres is that it
> would be done in a transaction otherwise what is the point ?

If addBatch was not meant to be called when autocommit=true, then it would have thrown an exception. The point is to enable multiple statement in 1 executeBatch call. Just imagine a system that separates who makes statements and who executes them. Like event logging lets say. Meanwhile, there are infinite cases where multiple statements are not (and must not) be in a all-or-nothing transaction. This is why applications choose to set autocommit=true to obtain the batch behavior without a TX. It's in the API for such reasons.

It is just incorrect to consider the batch is 1 transaction when the API clearly exposes the ability to avoid it. As I wrote earlier, calling applications that just pile up updates in a batch not expecting any deadlock due to row locking by each statement, will not work anymore.

The fact the API have autocommit independant from batches means it serve a purpose. I see it. But even if I didn't, the API says so and I can't second guess it.

I know it hurts to learn such truth after such a long delay. You'll get over it! lol! I have found a 4 year old bug lately, in my own code. I know the feeling. But I can't decide to call it a feature...lol

> If you agree with that then in the postgres world it would be natural
> for all of it to fail. At least thats how I would expect postgres to act.
>
> Dave