Fixed bug reported by Marko Strukelj and Keith Wannamaker. Using executeBatch

on a preparedStatement would reset the prepared statment causing subsequent
uses of the preparedStatement to fail (i.e. the following series of calls
would fail: addBatch() executeBatch() addBatch() executBatch()).  This is
a regression from 7.2 where this worked correctly.  The regression test has
also been modified to explicitly test for this case.

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
 	jdbc/org/postgresql/jdbc2/AbstractJdbc2Statement.java
 	jdbc/org/postgresql/test/jdbc2/BatchExecuteTest.java

1 files changed, 10 insertions, 2 deletions

diff --git a/src/interfaces/jdbc/org/postgresql/test/jdbc2/BatchExecuteTest.java b/src/interfaces/jdbc/org/postgresql/test/jdbc2/BatchExecuteTest.java
index 1c2569296be..e7f27ed575e 100644
--- a/src/interfaces/jdbc/org/postgresql/test/jdbc2/BatchExecuteTest.java
+++ b/src/interfaces/jdbc/org/postgresql/test/jdbc2/BatchExecuteTest.java
@@ -157,11 +157,19 @@ public class BatchExecuteTest extends TestCase
 		pstmt.executeBatch();
 		assertCol1HasValue(7);
 
-		con.commit();
+		//now test to see that we can still use the statement after the execute
+		pstmt.setInt(1, 3);
+		pstmt.addBatch();
 		assertCol1HasValue(7);
 
+		pstmt.executeBatch();
+		assertCol1HasValue(10);
+
+		con.commit();
+		assertCol1HasValue(10);
+
 		con.rollback();
-		assertCol1HasValue(7);
+		assertCol1HasValue(10);
 
 		pstmt.close();
 	}