This reverts commit eb570294a2.
That commit caused a regression, so it's probably best to revert it, and
to tackle the issue for the next minor release.
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.
Sammy Kaye Powers