On Wed, 29 Mar 2023 at 10:43, Denis Laxalde <denis.laxa...@dalibo.com> wrote: > More importantly, not having PQcancelSend() creating the PGcancelConn > makes reuse of that value, passing through PQcancelReset(), more > intuitive. E.g., in the tests:
You convinced me. Attached is an updated patch where PQcancelSend takes the PGcancelConn and returns 1 or 0. > The thing is that we need the connection encoding (client_encoding) when > eventually forwarding the result of PQcancelErrorMessage(), decoded, to > the user. Cancel connections don't have an encoding specified. They never receive an error from the server. All errors come from the machine that libpq is on. So I think you're making the decoding more complicated than it needs to be.
v18-0004-Add-non-blocking-version-of-PQcancel.patch
Description: Binary data
v18-0005-Start-using-new-libpq-cancel-APIs.patch
Description: Binary data
v18-0001-libpq-Run-pgindent-after-a9e9a9f32b3.patch
Description: Binary data
v18-0002-Copy-and-store-addrinfo-in-libpq-owned-private-m.patch
Description: Binary data
v18-0003-Return-2-from-pqReadData-on-EOF.patch
Description: Binary data
