Especially for remote servers, the respective part of the test may fail
for a lot of different reasons; instead of trying to catch all, we
rewrite to not fail, still testing for the contained NUL byte.
Closes GH-8451.
The ?array $ctorArgs = null parameter is changed to array $constructorArgs = [], and an additional memory leak revealed by the new test case is fixed.
Closes GH-6937
Co-Authored-By: Nikita Popov <nikita.ppv@gmail.com>
mysqlnd already creates interned zend_strings for us, so let's
make use of them.
This also required updating the PDO case changing code to work
with potentially shared strings. For the lowercasing, use the
optimized zend_string_tolower() implementation.
Like the test title and some comments in this test describe, this test
was supposed to have `::prepare()` failing because `LOAD DATA INFILE`
would not be supported as prepared statement, and then the test checks
whether follow-up queries would succeed. However, `LOAD DATA INFILE`
is supported for prepared statements at least on Windows with mysqlnd,
so the test does no longer test what it is supposed to do. Therefore,
we drop it.
Closes GH-6509.
libmysqlclient added this function in version 5.5, which happens
to be the minimum we support. If we have a prepared statement,
we should use it on both mysqlnd and libmysqlclient, even if the
handling afterwards is different.
This fixes error handling with native prepared statements.
The fact that getAttribute() fails for various libmysqlclient-only
options is a known issue, and the test was taking that into account.
However, the change of the default error mode broke the handling.
We need to handle the exceptions now.
Our minimum libmysqlclient version requirement is high enough
that we don't need to check for MYSQL_OPT_LOCAL_INFILE support.
However, the mysql_get_option() function seems to only be available
since 5.7 (though it's really hard to find any definitie information
on when MySQL introduced certain functions or changes...) so we
need to store the value of the flag locally to make it available
through getAttribute().
stmt->column_count gets reset before the next_rowset handler is
invoked, so we need to fetch the value from the result set instead.
Arguably PDO should be separating the destruction of the previous
result set and the switch to the next result set more cleanly...
Generate a param count mismatch error even if the query contains
no placeholders.
Additionally we shouldn't HANDLE errors from pdo_parse_params,
which are always reported via raise_impl_error. Doing so results
in duplicate error messages.
When a driver reports an error during EVT_ALLOC (and some over EVTs),
make sure we handle it as usual, i.e. warn or throw.
This requires some adjustments in PDO PgSQL to stop manually doing
this through an impl error.
Unfortunately the PDO PgSQL error messages regress because of this,
as they now include a completely arbitrary error code. There doesn't
seem to be an ability to skip it right now.
The actual behavior here is correct, but the previous error
message was misleading, as neither fetchAll() nor buffered queries
would help in this situation. Instead it is necessary to consume
all rowsets, which can be done by either unsetting the statement
or calling closeCursor().
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.
