Currently, internal classes are registered with the following code:
INIT_CLASS_ENTRY(ce, "InternalClass", class_InternalClass_methods);
class_entry = zend_register_internal_class_ex(&ce, NULL);
class_entry->ce_flags |= ...;
This has worked well so far, except if InternalClass is readonly. It is because some inheritance checks are run by zend_register_internal_class_ex before ZEND_ACC_READONLY_CLASS is added to ce_flags.
The issue is fixed by adding a zend_register_internal_class_with_flags() zend API function that stubs can use from now on. This function makes sure to add the flags before running any checks. Since the new API is not available in lower PHP versions, gen_stub.php has to keep support for the existing API for PHP 8.3 and below.
simplifying the workflow by just using PQreset which force a new
connection internally, connection process ids ought to be different,
and let the existing checks do the rest.
* 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.
* Include from build dir first
This fixes out of tree builds by ensuring that configure artifacts are included
from the build dir.
Before, out of tree builds would preferably include files from the src dir, as
the include path was defined as follows (ignoring includes from ext/ and sapi/) :
-I$(top_builddir)/main
-I$(top_srcdir)
-I$(top_builddir)/TSRM
-I$(top_builddir)/Zend
-I$(top_srcdir)/main
-I$(top_srcdir)/Zend
-I$(top_srcdir)/TSRM
-I$(top_builddir)/
As a result, an out of tree build would include configure artifacts such as
`main/php_config.h` from the src dir.
After this change, the include path is defined as follows:
-I$(top_builddir)/main
-I$(top_builddir)
-I$(top_srcdir)/main
-I$(top_srcdir)
-I$(top_builddir)/TSRM
-I$(top_builddir)/Zend
-I$(top_srcdir)/Zend
-I$(top_srcdir)/TSRM
* Fix extension include path for out of tree builds
* Include config.h with the brackets form
`#include "config.h"` searches in the directory containing the including-file
before any other include path. This can include the wrong config.h when building
out of tree and a config.h exists in the source tree.
Using `#include <config.h>` uses exclusively the include path, and gives
priority to the build dir.
This bumps the libpq client-side PostgreSQL library minimum required
version from 9.1 to 10.0.
- Sanity check: PQlibVersion -> PQencryptPasswordConn (available since
libpq 10.0)
- PQsetErrorContextVisibility (available since libpq 9.6)
- lo_truncate64 (available since libpq 9.3), if 32-bit system doesn't
support lo_*64 functions, error is returned and functions are always
available
Additionally, the conditional functions usages in pdo_pgsql and pgsql
extensions that got piled up are cleaned and synced:
- pg_prepare (PQprepare available since libpq 7.4)
- pg_query_params (PQexecParams available since libpq 7.4)
- pg_result_error_field (PQresultErrorField available since libpq 7.4)
- pg_send_prepare (PQsendPrepare available since libpq 7.4)
- pg_send_query_params (PQsendQueryParams available since libpq 7.4)
- pg_set_error_verbosity (PQsetErrorVerbosity available since libpq 7.4)
- pg_transaction_status (PQtransactionStatus available since libpq 7.4)
The Windows libpq version is currently at version 11.4:
https://github.com/winlibs/postgresql
Discussion: https://news-web.php.net/php.internals/123609
Follow-up of GH-14540
The pkg-config (libpq.pc file) was added in PostgreSQL 9.3. This adds a
common setup M4 macro PHP_SETUP_PGSQL to find client PostgreSQL library
libpq on the system with pkg-config. If not found, check falls back to
pg_config to find the libpq and its headers in common locations as
before.
The PGSQL_CFLAGS and PGSQL_LIBS environment variables can override the
libpq installation paths:
./configure --with-pgsql --with-pdo-pgsql \
PGSQL_CFLAGS=-I/path/to/libpq \
PGSQL_LIBS="-L/path/to/libpq -lpq"
Passing manual, non-standard PostgreSQL installation path can be done
with configure option arguments:
./configure \
--with-pgsql=/any/path/to/postgresql \
--with-pdo-postgresql=/any/path/to/postgresql
If this DIR argument (PostgreSQL installation directory or path to the
pg_config) is passed, it takes precedence over the pkg-config, when
installed on the system.
This also removes the unused HAVE_LIBPQ symbol and passing the
PGSQL_INCLUDE and PGSQL_LIBDIR environment variable to configure in
favor of PGSQL_CFLAGS and PGSQL_LIBS.
Instead of the obsolete backticks the recommended $(...) is used when
invoking the pg_config.
Follow-up of GH-4235 (Use PKG_CHECK_MODULES to detect the pq library)
The pg_encoding_to_char is available in PostgreSQL since ~7.3 where also
the --enable-multibyte option was removed. PHP minimum PostgreSQL
version at this point is 9.1, which also has the pg_encoding_to_char
declaration in libpq-fe.h.
This removes conditional usage and the HAVE_PGSQL_WITH_MULTIBYTE_SUPPORT
symbol.
The PG_VERSION_NUM is not available in intended public PostgreSQL
headers unless the pg_config.h is included or the PostgreSQL server
development headers are installed separately. This instead resorts to
checking for the PGVerbosity enum value. The PQERRORS_SQLSTATE was added
to PostgreSQL 12.0. At the time of writing, on Windows, PostgreSQL is at 11.4 so
it is not defined there yet.
Using PQSocketPoll to poll on a connection's socket.
Returns immediatly is there no event expected on read and write.
Other than that, it is a thin wrapper on top of poll, thus reflecting
its return value.
close GH-14366
pg_put_copy_data allows to send COPY commands to the server.
pg_put_copy_end signals the end of the n commands.
Both return 3 states ; 1, 0 and -1 when 1 is success, 0 the buffer queue
is full then -1 for errors.
Close GH-14325
On shutdown in ZTS the following happens:
- https://github.com/php/php-src/blob/master/Zend/zend.c#L1124-L1125
gets executed. This destroys global persistent resources and destroys
the modules. Furthermore, the modules are unloaded too.
- Further down, `ts_free_id(executor_globals_id)` gets executed, which
calls `executor_globals_dtor`. This function destroys persistent
resources for each thread.
Notice that in the last step, the modules that the persistent resource
belong to may already have been destroyed. This means that accessing
globals will cause a crash (I previously fixed this with ifdef magic),
or when the module is dynamically loaded we'll try jumping to a
destructor that is no longer loaded in memory. These scenarios cause
crashes.
It's not possible to move the `ts_free_id` call upwards, because that
may break assumptions of callers, and furthermore this would deallocate
the executor globals structure, which means that any access to those
will cause a segfault.
This patch adds a new API to the TSRM that allows running a callback on
a certain resource type. We use this API to destroy the persistent
resources in all threads prior to the module destruction, and keep the
rest of the resource dtor intact.
I verified this fix on Apache with postgres, both dynamically and
statically.
Fixes GH-12974.
