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
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
- New functions (each accepts a pgsql $connection resource):
. pg_connect_poll
. pg_socket
. pg_consume_input
. pg_flush
- Modified functions
The following functions now additionally return zero if the
underlying socket is set to non-blocking mode and the send
operation does not complete immediately. Previously these
functions returned only boolean TRUE/FALSE and blocked
execution while polling until all data was sent:
. pg_send_execute
. pg_send_prepare
. pg_send_query
. pg_send_query_params
- New constants
Used with pg_connect() to initiate an asynchronous connection
attempt:
. PGSQL_CONNECT_ASYNC
Used with pg_connection_status() to determine the current state
of an async connection attempt:
. PGSQL_CONNECTION_STARTED
. PGSQL_CONNECTION_MADE
. PGSQL_CONNECTION_AWAITING_RESPONSE
. PGSQL_CONNECTION_AUTH_OK
. PGSQL_CONNECTION_SSL_STARTUP
. PGSQL_CONNECTION_SETENV
Used with pg_connect_poll() to determine the result of an
async connection attempt:
. PGSQL_POLLING_FAILED
. PGSQL_POLLING_READING
. PGSQL_POLLING_WRITING
. PGSQL_POLLING_OK
. PGSQL_POLLING_ACTIVE
- Polling via returned pg_socket() stream
pg_socket() returns a read-only socket stream that may be
cast to a file descriptor for select (and similar) polling
operations. Blocking behavior of the pgsql connection socket
can be controlled by calling stream_set_blocking() on the
stream returned by pg_socket().
Peter Kokot