PDO MySQL: Normalize handling of empty stored procedure result set

MySQL always returns a trailing empty result set for stored
procedure calls, which is used to convey status information.
The PDO MySQL implementation is presently confused about what to
do with it: If mysqlnd is used and native prepared statements are
used, this result set is skipped. In all other cases it is not
skipped. We also have quite a few XFAILed tests relating to this.

This patch normalizes (for PHP-8.0 only) the behavior towards
always retaining the empty result set. This is simply how MySQL
stored procedures work (some expletives omitted here) and we can't
distinguish this "useless" result set from an empty result of a
multi query. Multi queries are not a concern for native prepared
statements, as PDO does not allow them in that case, but they are
a concern for emulated prepared statements.

Closes GH-6497.

1 files changed, 0 insertions, 10 deletions

diff --git a/ext/pdo_mysql/mysql_statement.c b/ext/pdo_mysql/mysql_statement.c
index c8a6a218ab..9d544b23c2 100644
--- a/ext/pdo_mysql/mysql_statement.c
+++ b/ext/pdo_mysql/mysql_statement.c
@@ -359,16 +359,6 @@ static int pdo_mysql_stmt_next_rowset(pdo_stmt_t *stmt) /* {{{ */
 			PDO_DBG_RETURN(0);
 		}
 
-		if (!mysqlnd_stmt_more_results(S->stmt)) {
-			/*
-			MySQL gives us n + 1 result sets for
-			CALL proc() and n result sets returned by the proc itself.
-			Result set n + 1 is about the procedure call itself.
-			As the PDO emulation does not return it, we skip it as well
-			*/
-			PDO_DBG_RETURN(0);
-		}
-
 		/* TODO - this code is stolen from execute() - see above */
 		if (S->result) {
 			mysql_free_result(S->result);