When we receive an error while reading a result set, we should
assume that no more result sets are available. libmysqlclient
implements the same behavior.
Keep track of whether we have fully consumed all result sets,
either using nextRowset() calls or closeCursor() and skip the
attempt to consume remaining results sets during destruction in
that case.
Especiall if closeCursor() has been used, we really shouldn't
have this sort of cross-statement inference.
This was already working in all cases apart from native prepared
statements with unbuffered queries. In that case invoking
stmt_free_result() addresses the issue.
Two bugs both affecting the bug_pecl_7976.phpt test ("works with
mysqlnd" haha):
* We should not change the connection state in stmt_free_result.
This makes mysql_stmt_free_result usable under mysqlnd and
not just libmysqlclient.
* If we call mysql_stmt_free_result, we still need to consume
any outstanding result sets.
If the count changes from prepare to execute and result_bind is
alreadly allocated, reallocate it there.
This is something of a hack. It would be cleaner to require that
result bindings are registered only after execute, when the final
result set fields are known. But mysqli at least directly exposes
this to the user, so we have no guarantee.
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.
This has been fixed for PDO SQlite by GH-4313, however the same
issue also applied to PDO MySQL.
Move the column count setting function into the main PDO layer
(and export it) and then use it in both PDO SQLite and PDO MySQL.
If there is no result set (e.g. for upsert queries), still allow
fetching to occur without error, i.e. treat it the same way as
an empty result set.
This normalizes behavior between native and emulated prepared
statements and addresses a regression in PHP 7.4.13.
By simply dropping the additional checks, in line with the general
guideline of trusting the output of config scripts (this should
be migrated to pkg-config though).
Also drop the code for manually adding -z if mysql_config does not
-- that's not our problem.
The EOF flag also gets set on error, so we always end up ignoring
errors here.
However, we should only check errors for unbuffered results. For
buffered results, this function is guaranteed not to error, and
querying the errno may return an unrelated error.
Make sure deadlock errors are properly propagated and reports in
a number of places in mysqli and PDO MySQL.
This also fixes a memory and a segfault that can occur under these
conditions.
This addresses an issue introduced by #4996 and reported in
https://bugs.php.net/bug.php?id=80260.
Now that PDO::inTransaction() reports the real transaction state
of the connection, there may be a mismatch with PDOs internal
transaction state (in_tcx). This is compounded by the fact that
MySQL performs implicit commits for DDL queries.
This patch fixes the issue by making beginTransaction/commit/rollBack
work on the real transaction state provided by the driver as well
(or falling back to in_tcx if the driver does not support it).
This does mean that writing something like
$pdo->beginTransaction();
$pdo->exec('CREATE DATABASE ...');
$pdo->rollBack(); // <- illegal
will now result in an error, because the CREATE DATABASE already
committed the transaction. I believe this behavior is both correct
and desired -- otherwise, there is no indication that the code did
not behave correctly and the rollBack() was effectively ignored.
However, this is also a BC break.
Closes GH-6355.
Followup to previous changes:
* Use camel case, as PDO uses a camel case OO API.
* Use &$var instead of &$bind_var or &$param.
* Use $column instead of $index. We have cases (both inside PDO
and in other DB exts) where columns can also be represented as
strings, so $column is the safer generic name.
Closes GH-6272.
