> I'm coming around to the position that we shouldn't tinker
> with
> autoCommit within the executeBatch method. I still
> think it would
> be best for us to consistently bail out on the first
> failure, but if
> autoCommit is on, we could build the BatchUpdateException
> using an
> array of the length of the successfully completed
> statements. If
> autoCommit is off, I'm not sure whether it would be better
> to leave
> the updateCounts property null or use a zero length array;
> but
> clearly no statements should be considered successful.
>
> The API documentation does seem to suggest it should work
> that way.
>
> The bad news is that this would be a behavior change, and
> could thus
> break existing code for current PostgreSQL users.
> When that's the
> case, we generally like to see a reasonable use case for
> the new
> behavior even when it is standard. So far we have a
> rather
> hand-wavy assertion that it would be useful for logging and
> "an
> infinite number of" other uses. It would probably
> help sway the
> community if there was a more concrete explanation of why
> this was
> better than the alternatives for logging purposes, and to
> sketch out
> one or two of the other infinite number of use cases.
You have been defending all that long that most use the autocommit=false when using batches. Then they won't break....!
Besides that's what release notes are for. And I dare say, if they expected a transaction when using a batch with
autocommit=true,it about time they learn their mistake. JDBC api is a contract. Can't make exception for postgres.