Calling sqlite3_reset() when a result set object is freed can cause
undesired and maybe even hard to track interference with other result
sets. Furthermore, there is no need to call sqlite3_reset(), because
that is implicitly called on SQLite3Stmt::execute(), and users are
encouraged to explicitly call either SQLite3Result::finalize() or
SQLite3Stmt::reset() anyway.
FTS3 is already enabled by default, and the other FTS versions
seems just to have been missed. Given that, the other FTS plugins
look like a low impact so worth a try. The current bundled libsqlite
versions in 7.x are proven stable already and support FTS5.
We return all integers that can be represented as such by PHP as
integers, and only those that exceed the possible range as strings.
On builds which represent integers with 64 bits, the range check is
unnecessary and might cause code checkers to complain, so we skip this
special casing via the preprocessor according to
<http://git.php.net/?p=php-src.git;a=commit;h=99d087e5>.
When ran from a root directory the test case failed, because the open_basedir
restriction for "../[…]" won't kick in. Therefore we change the current
working directory to the test case's directory, as discussed on internals,
see <http://news.php.net/php.internals/95585>.
From the [sqlite3_open](https://www.sqlite.org/c3ref/open.html) docs:
| If the filename is an empty string, then a private, temporary on-disk
| database will be created. This private database will be automatically
| deleted as soon as the database connection is closed.
We make that facility available to userland.
While we're at it, we also do some minor optimizations, remove the
unnecessary check for NUL characters in filename, which is already catered
to by ZPP(p), and add a missing `return` in case db_obj isn't initialized.
This implements a reduced variant of #1226 with just the following
change:
-Fatal error: Uncaught exception 'EngineException' with message 'Call to private method foo::bar() from context ''' in %s:%d
+Fatal error: Uncaught EngineException: Call to private method foo::bar() from context '' in %s:%d
The '' wrapper around messages is very weird if the exception
message itself contains ''. Futhermore having the message wrapped
in '' doesn't work for the "and defined" suffix of
TypeExceptions.
Introduces a ZEND_PARSE_PARAMS_THROW flag for zpp, which forces to
report FAILURE errors using a TypeException instead of a Warning,
like it would happen in strict mode.
Adds a zend_parse_parameters_throw() convenience function, which
invokes zpp with this flag.
Converts all cases I could identify, where we currently have
throwing zpp usage in constructors and replaces them with this API.
Error handling is still replaced to EH_THROW in some cases to handle
other, domain-specific errors in constructors.
