* main: Ignore `register_argc_argv` when `SG(request_info).argc` is available
* sapi: Remove hardcoded `register_argc_argv` for CLI SAPIs
This INI is ignored since the previous commit, which makes the hardcoded
setting obsolete.
* main: Deprecate deriving $_SERVER['argc'] and $_SERVER['argv'] from the query string
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_the_register_argc_argv_ini_directive
* main: Adjust deprecation message for `register_argc_argv`
* NEWS/UPGRADING
* Purge most special cases for building ODBC with specific drivers
PDO_ODBC doesn't do this, and most of these drivers are not in use with
PHP, at least like this. Chances are these expose an ODBC driver you can
use with a normal driver manager like unixODBC or iODBC. If not, it can
be specified as a custom driver, though it does not include any
workarounds.
There might be some redundant definitions now as a result.
IBM Db2 is kept as a special case due to it also being in PDO_ODBC,
though I wonder how good of an idea this is.
See GH-15630
* Remove never used include
This would only be used on 68k classic Mac OS. Did PHP ever run there?
* Fold HAVE_SQL_EXTENDED_FETCH
All supported driver managers can do extended fetches.
* Ope, accidentally deleted this in a refactor
* All driver managers support SQLDataSources now too
So we don't need the define?
* Remove undef CHAR
There's no justification behind as to why this should be.
* Don't special case SQL_TIMESTAMP
The default handling for turning into SQL_C_CHAR is fine, and the
special case for Adabas is no longer needed.
* Assume fetch_hash is always possible
The driver managers and even Db2 support this.
This would also allow simplifying the fetch code to merge fetch_into and
fetch_array into a single implementation perhaps.
* Update UPGRADING for driver specific removal
* Update NEWS for driver specific removal
This commit implements GH-8967.
SQLite supports multiple transaction modes. These include:
- DEFERRED (default) only acquires a lock when you start a read/write
- IMMEDIATE acquires a reserved lock
- EXCLUSIVE acquires an exclusive lock (stricter than immediate)
In WAL mode IMMEDIATE and EXCLUSIVE are identical.
One reason for wanting to specify a transaction mode is that SQLite
doesn't respect busy_timeout when a DEFERRED transaction tries to
upgrade a read lock to a write lock. Normally if you try to acquire a
lock and have busy_timeout configured, SQLite will wait for that period
until giving up and erroring out (SQLITE_BUSY). With DEFERRED, if you
have a transaction that first reads and there's a concurrent writer
while it's trying to upgrade to a write lock, you will immediately get
SQLITE_BUSY regardless of your busy_timeout.
Prior to this commit, the only available workarounds were:
- Using $pdo->exec("BEGIN IMMEDIATE TRANSACTION") instead of
$pdo->beginTransaction()
- Doing a dummy write at the start of each transaction so you don't get
stuck with a read lock
Both of those aren't very usable, especially in a framework context
where the user doesn't have complete control over how transactions are
started.
To address that, this commit adds four class constants to Pdo\Sqlite:
- ATTR_TRANSACTION_MODE -- a new attribute
- TRANSACTION_MODE_DEFERRED = 0
- TRANSACTION_MODE_IMMEDIATE = 1
- TRANSACTION_MODE_EXCLUSIVE = 2
These can be used as:
$pdo->setAttribute(
$pdo::ATTR_TRANSACTION_MODE,
$pdo::TRANSACTION_MODE_IMMEDIATE
);
Introduce the TAILCALL VM, a more efficient variant of the CALL VM:
* Each opcode handler tailcalls the next opcode handler directly instead of
returning to the interpreter loop. This eliminates call and interpreter loop
overhead.
* Opcode handlers use the preserve_none calling convention to eliminate
register saving overhead.
* preserve_none uses non-volatile registers for its first arguments, so
execute_data and opline are usually kept in these registers and no code is
required to forward them to the next handlers.
Generated machine code is similar to a direct-threaded VM with register pinning,
like the HYBRID VM.
JIT+TAILCALL VM also benefits from this compared to JIT+CALL VM:
* JIT uses the registers of the execute_data and opline args as fixed regs,
eliminating the need to move them in prologue.
* Traces exit by tailcalling the next handler. No code is needed to forward
execute_data and opline.
* No register saving/restoring in epilogue/prologue.
The TAILCALL VM is used when the HYBRID VM is not supported, and the compiler
supports the musttail and preserve_none attributes: The HYBRID VM is used when
compiling with GCC, the TAILCALL VM when compiling with Clang>=19 on x86_64 or
aarch64, and the CALL VM otherwise.
This makes binaries built with Clang>=19 as fast as binaries built with GCC.
Before, these were considerably slower (by 2.8% to 44% depending on benchmark,
and by 5% to 77% before 76d7c616bb).
Closes GH-17849
Closes GH-18720
* Remove references to ODBCVER and assume ODBC 3.x
See https://wiki.php.net/rfc/deprecations_php_8_5#remove_support_for_older_odbc_versions
* Avoid calling deprecated ODBC functions
`SQLGetConnectOption`, `SQLSetConnectOption` and `SQLSetStmtOption` are
deprecated, so if ODBC 3 is available, we use `SQLSetConnectAttr`,
`SQLGetConnectAttr`, and `SQLSetStmtAttr` instead.
(This is based on GH-17556, but just assumes ODBC 3.x.)
* Remove wrappers for SQLColAttribute
We don't need to support the old way of doing it.
* Just call SQLAllocHandle directly
Again, no need for the version specific wrapper
* Update NEWS for ODBCVER in beta2
* [skip ci] UPGRADING for ODBCVER changes
---------
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
The allows cipher_algo to be specified as a string. It means the not
only predefined ID ciphers are available which means that also auth
enveloped data can be created using AES GCM.
Closes GH-19459
This adds PKCS7_NOSMIMECAP, PKCS7_CRLFEOL, PKCS7_NOCRL and
PKCS7_NO_DUAL_CONTENT constants. They might be potentially useful
in some scenarious.
Test is not added as it is not clear if there is much need for those and
it would require much bigger effort just to test OpenSSL functionality.
Closes GH-19450
