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
