Re: Deleting prepared statements from libpq.

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