Besides the common `:param` notation to designate named parameters in
prepared statements, SQLite3 also supports `@param` and `$param`.
While the latter is mostly to support the Tcl programming language, and
would be confusing for PHP's sqlite3 binding due to the similarity with
string interpolation, the former is common under .NET and raises no
such issue. Therefore we add support for it.
This patch has been developed in cooperation with @BohwaZ.
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
Since there is no need to patch libsqlite3 for our purposes, and since
libsqlite3 ≥ 3.3.9 (which is our current requirement) is widely
available on distros, there is no reason anymore to bundle the library.
Besides removing the bundled libsqlite, and adapting the configuration
respectively, we also fix the use of the SQLITE_ENABLE_COLUMN_METADATA
compile time constant to detect whether sqlite3_column_table_name() is
available by a working feature detection (otherwise bug_42589.phpt
would fail). We also skip bug73068.phpt for libsqlite 3.11.0 to
3.14.1 which have a bug (<https://sqlite.org/src/info/ef360601>).
We also completely drop support for the obscure pdo_sqlite_external
extension (which could have been enabled on Windows only by passing
`--pdo-sqlite-external` to configure), since it is not needed anymore.
Furthermore, we remove references to the bundled libsqlite from
Makefile.gcov, CONTRIBUTING.md and README.REDIST.BINS.
SQLITE_DETERMINISTIC only exists in recent version
e.g. missing on 3.7 which is the default on RHEL/CentOS-7
and probably others (wheezy have 3.7, jessie 3.8...)
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.
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>.
