Craig Ringer wrote:
> Updated patch attached.
Please find attached a couple fixes for typos I've came across in
the doc part.
Also it appears that PQqueriesInBatch() doesn't work as documented.
It says:
"Returns the number of queries still in the queue for this batch"
but in fact it's implemented as a boolean:
+/* PQqueriesInBatch
+ * Return true if there are queries currently pending in batch mode
+ */+int
+PQqueriesInBatch(PGconn *conn)
+{
+ if (!PQisInBatchMode(conn))
+ return false;
+
+ return conn->cmd_queue_head != NULL;
+}
However, is this function really needed? It doesn't seem essential to
the API. You don't call it in the test program either.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 73c6c03..af4f922 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -4653,7 +4653,7 @@ int PQflush(PGconn *conn);
</programlisting>
could be much more efficiently done with:
<programlisting>
- UPDATE mytable SET x = x + 1;
+ UPDATE mytable SET x = x + 1 WHERE id = 42;
</programlisting>
</para>
@@ -4696,7 +4696,7 @@ int PQflush(PGconn *conn);
<link linkend="libpq-pqsetnonblocking">non-blocking mode</link>. If used
in
blocking mode it is possible for a client/server deadlock to occur. The
client will block trying to send queries to the server, but the server
will
- block trying to send results from queries it's already processed to the
+ block trying to send results from queries it has already processed to the
client. This only occurs when the client sends enough queries to fill its
output buffer and the server's receive buffer before switching to
processing input from the server, but it's hard to predict exactly when
@@ -5015,7 +5015,7 @@ int PQgetNextQuery(PGconn *conn);
<listitem>
<para>
Returns the number of queries still in the queue for this batch, not
- including any query that's currently having results being processsed.
+ including any query that's currently having results being processed.
This is the number of times <function>PQgetNextQuery</function> has to be
called before the query queue is empty again.
@@ -5037,7 +5037,7 @@ int PQqueriesInBatch(PGconn *conn);
<listitem>
<para>
- Returns 1 if the batch curently being received on a
+ Returns 1 if the batch currently being received on a
<application>libpq</application> connection in <link
linkend="libpq-batch-mode">batch mode</link> is
<link linkend="libpq-batch-errors">aborted</link>, 0
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
