Missing error checking could result in SQL injection and missing error handling could lead to crashes due to null pointer dereferences.

This is related to https://www.postgresql.org/support/security/CVE-2025-1094/ that was reported to postgres. The reporter used php to showcase the problem.

While working on addressing the report, it was realised that PHP uses the escape functions in a way that does not allow for errors to be reported. Specifically the error parameters is not passed to PQescapeStringConn(), which therefore cannot report an error.

While postgres now tries to make sure that the escaped string will trigger errors on the server-side if the string is invalidly encoded, that still can be insufficient, depending on how the escaped values are used.

It was also noted that several calls to PQescapeIdentifier() do not check for the returned value being NULL, despite that being the documented way that PQescapeIdentifier() (and PQescapeLiteral()) to report errors. Seems like that could cause crashes or at least UB in some of the callsites.