On Sun, Jun 18, 2023 at 01:03:57PM +0200, Jelte Fennema wrote: > Sorry about that. I attached a new patch that allows linking to the > new functions (I forgot to add the functions to exports.txt). This new > patch also adds some basic tests for these new functions.
I am okay with the arguments about pgbouncer and psycopg2. The symmetry with the portal description routines makes this proposal easy to think about. - PGQUERY_CLOSE + PGQUERY_CLOSE /* Close Statoment or Portal */ s/Statoment/Statement/. + * Available options for close_type are + * 'S' to close a prepared statement; or + * 'P' to close a portal. + * Returns 1 on success and 0 on failure. + */ +static int +PQsendClose(PGconn *conn, char close_type, const char *close_target) Could it be better for this code path to issue an error if using a non-supported close_type rather than sending it? Okay, you are consistent with desc_type and PQsendDescribe(), just asking if it is worth doing something about. + <listitem> + <para> + Submits a request to obtain information about the specified + prepared statement, and waits for completion. +<synopsis> PQclosePrepared() does not request for a description. + Submits a request to close the the specified + portal, and waits for completion. s/the the/the/. + <xref linkend="libpq-PQclosePortal"/> allows an application to release + resources related to a portal previously created portal. If it was a The end of this sentence looks a bit weird. Perhaps there should be some tests for the two async routines, as well? -- Michael
signature.asc
Description: PGP signature
