> 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
enablemultiple statement in 1 executeBatch call. Just imagine a system that separates who makes statements and who
executesthem. Like event logging lets say. Meanwhile, there are infinite cases where multiple statements are not (and
mustnot) be in a all-or-nothing transaction. This is why applications choose to set autocommit=true to obtain the batch
behaviorwithout 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
wroteearlier, calling applications that just pile up updates in a batch not expecting any deadlock due to row locking
byeach 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
APIsays 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
