Fix libpq so that it reports PGRES_EMPTY_QUERY not PGRES_COMMAND_OK when an

empty query string is passed to PQexecParams and related functions.  Its
handling of the NoData response to Describe messages was subtly incorrect.
Per my report of yesterday.

Although I consider this a bug, it's a behavioral change that might affect
applications, so not back-patched.

In passing fix a second issue in the same code: it didn't react well to an
out-of-memory failure while trying to make the PGresult object.

1 files changed, 15 insertions, 10 deletions

diff --git a/src/interfaces/libpq/fe-protocol3.c b/src/interfaces/libpq/fe-protocol3.c
index d58aabb46f..2bd5f5aa20 100644
--- a/src/interfaces/libpq/fe-protocol3.c
+++ b/src/interfaces/libpq/fe-protocol3.c
@@ -297,19 +297,24 @@ pqParseInput3(PGconn *conn)
 					/*
 					 * NoData indicates that we will not be seeing a
 					 * RowDescription message because the statement or portal
-					 * inquired about doesn't return rows. Set up a COMMAND_OK
-					 * result, instead of TUPLES_OK.
-					 */
-					if (conn->result == NULL)
-						conn->result = PQmakeEmptyPGresult(conn,
-														   PGRES_COMMAND_OK);
-
-					/*
-					 * If we're doing a Describe, we're ready to pass the
-					 * result back to the client.
+					 * inquired about doesn't return rows.
+					 *
+					 * If we're doing a Describe, we have to pass something
+					 * back to the client, so set up a COMMAND_OK result,
+					 * instead of TUPLES_OK.  Otherwise we can just ignore
+					 * this message.
 					 */
 					if (conn->queryclass == PGQUERY_DESCRIBE)
+					{
+						if (conn->result == NULL)
+						{
+							conn->result = PQmakeEmptyPGresult(conn,
+															PGRES_COMMAND_OK);
+							if (!conn->result)
+								return;
+						}
 						conn->asyncStatus = PGASYNC_READY;
+					}
 					break;
 				case 't':		/* Parameter Description */
 					if (getParamDescriptions(conn))