Always Describe a query in a batch that returns generated keys

This is a workaround for issue #267, where we unprepare a statement
in a batch when the parameter types change but we expect to still
know the field types in the statement we just unprepared.

It's much more complicated than that, see
#267 for the gory details.

org/postgresql/core/QueryExecutor.java

@@ -88,6 +88,13 @@ public interface QueryExecutor {
      * both the ResultSet and associated update count from the command status.
      */
     static int QUERY_BOTH_ROWS_AND_STATUS = 64;
+
+    /**
+     * Force this query to be described at each execution. This is done in
+     * pipelined batches where we might need to detect mismatched result
+     * types.
+     */
+    static int QUERY_FORCE_DESCRIBE_PORTAL = 128;
 
     /**
      * Flag to disable batch execution when we expect results (generated keys)

org/postgresql/core/v3/QueryExecutorImpl.java

@@ -1624,6 +1624,7 @@ private void sendOneQuery(SimpleQuery query, SimpleParameterList params, int max
         boolean usePortal = (flags & QueryExecutor.QUERY_FORWARD_CURSOR) != 0 && !noResults && !noMeta && fetchSize > 0 && !describeOnly;
         boolean oneShot = (flags & QueryExecutor.QUERY_ONESHOT) != 0 && !usePortal;
         boolean noBinaryTransfer = (flags & QUERY_NO_BINARY_TRANSFER) != 0;
+        boolean forceDescribePortal = (flags & QUERY_FORCE_DESCRIBE_PORTAL) != 0;
 
         // Work out how many rows to fetch in this pass.
 
@@ -1692,18 +1693,24 @@ else if (maxRows != 0 && fetchSize > maxRows)
 			/*
 			 * don't send describe if we already have cached the row description
 			 * from previous executions
-			 *
-			 * XXX Clearing the fields / unpreparing the query is incorrect, see
-			 * bug #267. We might clear the cached fields in a later execution
-			 * of this query if the bind parameter types change, but we're
-			 * assuming here that they'll still be valid when we come to process
-			 * the results of this query, so we don't send a new describe here.
-			 * We re-describe after the fields are cleared, but the result of
-			 * that gets processed after processing the results from earlier
-			 * executions that we didn't describe because we didn't think we had
-			 * to.
+			 * 
+			 * XXX Clearing the fields / unpreparing the query (in sendParse) is
+			 * incorrect, see bug #267. We might clear the cached fields in a
+			 * later execution of this query if the bind parameter types change,
+			 * but we're assuming here that they'll still be valid when we come
+			 * to process the results of this query, so we don't send a new
+			 * describe here. We re-describe after the fields are cleared, but
+			 * the result of that gets processed after processing the results
+			 * from earlier executions that we didn't describe because we didn't
+			 * think we had to.
+			 * 
+			 * To work around this, force a Describe at each execution in
+			 * batches where this can be a problem. It won't cause more round
+			 * trips so the performance impact is low, and it'll ensure that the
+			 * field information available when we decoded the results. This
+			 * is undeniably a hack, but there aren't many good alternatives.
 			 */
-			if (query.getFields() == null) {
+			if (query.getFields() == null || forceDescribePortal) {
 				sendDescribePortal(query, portal);
 			}
 		}

org/postgresql/jdbc2/AbstractJdbc2Statement.java

@@ -2905,6 +2905,12 @@ public int[] executeBatch() throws SQLException
             // we'll be able to queue up before we risk a deadlock.
             // (see v3.QueryExecutorImpl's MAX_BUFFERED_RECV_BYTES)
             preDescribe = wantsGeneratedKeysAlways && !queries[0].isStatementDescribed();
+            /*
+             * It's also necessary to force a Describe on the first execution of the
+             * new statement, even though we already described it, to work around
+             * bug #267.
+             */
+            flags |= QueryExecutor.QUERY_FORCE_DESCRIBE_PORTAL;
         }
 
         if (connection.getAutoCommit())