pgjdbc: ReturnCodes of BatchExecutionException getUpdateCounts()

Since issue #502 (https://github.com/pgjdbc/pgjdbc/issues/502) the result of the BatchUpdateException.getUpdateCounts() changed: If one statement fails, the postgres driver marks all updateCounts as Statement.EXECUTE_FAILED no mater whether the statement is successfully executed or not.

So the question is “if the driver should mark all the rows in int[] executeBatch() with Statement.EXECUTE_FAILED” when a single statement fails.

Since issue 502 this question is answered with YES. I think this is not correct.

I wrote a test programm to demonstrate this: https://github.com/tillmann73/updCountTest/tree/master/src

I have a simple test program which first creates a testtable, fills it with one record and does a batch insert of 10 records. The 5th insert causes a BatchUpdateException at stmt.executeBatch() when the data is NOT commited.

The correct result of the programm is {1,1,1,1,1} This result was returned by postgres before the change. The same result is also returned by the oracle jdbc database driver.

With the new postgres driver the result is {-3,-3,-3,-3,-3,-3,-3,-3,-3,-3}

This is not what javadoc defines for getUpdateCounts():

    int[] getUpdateCounts() return an array of int containing the update counts for the updates that were executed successfully before this error occurred.  
    Or, if the driver continues to process commands after an
        * error, one of the following for every command in the batch:
        * an update count
        * Statement.SUCCESS_NO_INFO
        * Statement.EXECUTE_FAILED< to indicate that the command failed to execute successfully

The following arguments would speak against the current implementation of issue #502

• In the test programm the driver returns wrong information. Statements 0…4 are executed successfully.
• In the test programm the driver returns wrong information. Statements 0…4 are executed successfully.
• Returning -3 for all statements is a loss of information. I need to know, which statements of the batch are successful.
• The change in issue #502 is a bigger change and programs need to be changed. It is a break with the backward compatibility.
• Other drivers like oracle-jdbc work the same way like postgres does before issue #502 was released. When writing programs , which are using different database vendors, it is helpfull if the driver

The fix would be to remove the code of issue #502 from the driver.