The conversion of the data parameter to Z_PARAM_PATH_STR() made
pg_lo_write() reject any data containing a null byte, breaking writes of
arbitrary binary payloads which were accepted before. Accept embedded
null bytes again by parsing the data as a length-aware string. Sibling
audit: the other Z_PARAM_PATH* conversions from the same change
(pg_connect(), pg_lo_import(), table/statement identifiers) operate on
paths or SQL text where null-byte rejection is intentional.
Closes GH-23649
pg_update() and pg_delete() list PGSQL_DML_ASYNC among the valid flags in
the error they raise, although their masks reject it and their helpers
assert it is never set. Conversely pg_insert() and pg_update() accept the
whole PGSQL_CONV_OPTS set but only named PGSQL_CONV_FORCE_NULL, so
PGSQL_CONV_IGNORE_DEFAULT and PGSQL_CONV_IGNORE_NOT_NULL are added.
While there, widen php_pgsql_delete()'s assert to PGSQL_DML_NO_CONV,
which pg_delete() accepts and the helper itself consults.
Close GH-23480
Splitting the behavioural change of #23052 out into this and come up with something that is hopefully more sensible and consistent between fast and slow ZPP and the object or class_name Fast ZPP specifier.
The stub spelled it Pgsql\Connection, the only such spelling in the
extension. Resolution is case-insensitive, but Reflection reported a
class name that does not match the declared one.
Close GH-23393
Prevents unavailable optional test services from slowing the suite through repeated connection timeouts. PDO and SNMP availability probes cache the first failure for the duration of one test run, so later SKIPIF checks return immediately.
Only failures are cached; successful probes and test connections are unchanged. PDOs one second timeout applies only to the default availability probe. The caches are private, run-scoped and removed afterwards. A service becoming available mid run is detected on the next test-suite run.
php_pgsql_add_quotes() quotes the string with E'...', but PQescapeStringConn()
does not escape \ unless standard_conforming_strings is off.
PQescapeStringConn() is meant to be used with '', so do that instead.
Fixes GHSA-7qpv-r5mr-78m4
Move object_init_ex() before php_pgsql_fetch_hash() so abstract,
interface and enum errors surface earlier, look up the constructor
via the get_constructor handler (under EG(fake_scope)) so classes
with overridden handlers work, and mark the object as ctor-failed
when the constructor throws.
The ValueError for ctor args on a class without a constructor now
reports argument 4 ($constructor_args) instead of argument 3 ($class).
close GH-21884
The PHP_PQ_ERROR macro calls php_error_docref() which triggers user error handlers
thus libpq does not have the chance to clean the resources (and empty
connections string are allowed) on failure thus we avoid this macro
and delay the error handling after.
close GH-21165
This adds error checks for escape function is pgsql and pdo_pgsql
extensions. It prevents possibility of storing not properly escaped
data which could potentially lead to some security issues.
This adds error checks for escape function is pgsql and pdo_pgsql
extensions. It prevents possibility of storing not properly escaped
data which could potentially lead to some security issues.
This adds error checks for escape function is pgsql and pdo_pgsql
extensions. It prevents possibility of storing not properly escaped
data which could potentially lead to some security issues.
up to postgresql 17, when done with a prepared statement, we could
release it with DEALLOCATE sql command which is fine ; until we want
to implement a cache solution based on statement ids.
Since PostgreSQL 17, PQclosePrepared uses internally the `close` protocol
allowing to reuse the statement name while still freeing it.
Since the close protocol implementation had been added on libpq within
this release, no way to reimplement it.
close GH-14584
* ext/dba/tests/setup/setup_dba_tests.inc: sort test output
Iterating through a database with firstkey() and nextkey() is
guaranteed to retrieve all rows, but apparently not in any particular
order. This is causing a test failure for at least one user, so we
steal the sort() approach from GDBM to ensure that the output is
predictable.
* ext/dba/tests/dba_*.phpt: sort expected test output
The actual output is now sorted for consistency, so we need to update
the expected output as well. As a nice side effect, some differences
in the expected outputs for the various engines have been eliminated.
Closes GH-14786
* ext/pgsql/tests/80_bug14383.phpt: sort expected test output
This test uses a routine from ext/dba that now sorts its (actual)
output, so we have to sort the expected output here as well.
* ext/dba/tests/setup/setup_dba_tests.inc: update comment
After doing some more digging, it looks like GDBM isn't the only
engine where the iteration order with firstkey() and nextkey()
might change unexpectedly.
David Carlier