| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Previously boolean parameters were simply silently ignored...
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| | |
* PHP-7.4:
Drop pdo_mysql_prepare_load_data.phpt
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
Following cmb's suggestion and replacing the counter with a check
against the bound_params HT, which ensures that both cannot go
out of sync.
|
| |
| |
| |
| |
| |
| | |
The logic after next_result should match the one after execute.
This was the case for mysqlnd but not libmysqlclient, which used
the non-PS logic.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This test was always skipped (leftover debug statement?)
Contrary to the comments in the test and the test expectation,
this actually works fine.
|
| |
| |
| |
| |
| |
| |
| | |
Repeated execute() with native PS failed to release the previous
result set on libmysqlclient.
Move freeing the result set into a common location.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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...
|
| |
| |
| |
| |
| |
| | |
And remove unnecessary try-catch.
Closes GH-6505.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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().
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fixed bug #76815
|
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fixed bug #71145
|
| |
| |
| |
| | |
Consume any additional result sets when running INIT_COMMAND.
|
| |
| |
| |
| |
| |
| |
| | |
Given the number of duplicates this bug report had, it seems
worthwhile to fix this on PHP-7.4 as well.
Cherry-pick of 106e7e4bca7c0fd975eb219b18e3c34957ba8657.
|
| |
| |
| |
| |
| | |
If we fall back to emulated prepared statements, destroy S->stmt,
so the code doesn't get confused about which mode we're in.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Just calling next_result() is sufficient.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fixed bug #78154
|
| |
| |
| |
| | |
Handle errors during next_result in exec.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
This one had a rather scary XFAIL message, but seems to work just
fine...
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fixed bug #63185
|
| | |
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fixed bug #80458
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fix #80312: change default engine from MyISAM to InnoDB in tests
|
| |
| |
| |
| |
| |
| |
| | |
Change mysqli and pdo_mysql tests configuration to use by default
InnoDB instead of MyISAM.
Closes GH-6405.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Closes GH-6390.
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Handle errors during PDO row fetch
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fixed bug #66528
|
| |
| |
| |
| | |
Report errors in commit, rollback and autocommit handlers.
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
Fix bug #79375
|