Re: JDBC gripe list (the autocommit subthread) - Mailing list pgsql-jdbc

From Kevin Grittner
Subject Re: JDBC gripe list (the autocommit subthread)
Date
Msg-id 4D945B75020000250003BFF6@gw.wicourts.gov
Whole thread Raw
In response to Re: JDBC gripe list (the autocommit subthread)  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: JDBC gripe list (the autocommit subthread)  (Quartz <quartz12h@yahoo.com>)
List pgsql-jdbc
`Kevin Grittner <Kgrittn@wicourts.gov> wrote:

> There's an array in that exception class.

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.

-Kevin

pgsql-jdbc by date:

Previous
From: "David Patricola"
Date:
Subject: Re: SSL connection failure
Next
From: BozhkoKA
Date:
Subject: Cannot open connection while insert much data.