On Thu, May 8, 2014 at 1:51 PM, Tom Lane <[email protected]> wrote:
> Robert Haas <[email protected]> writes:
>> OK. It still seems to me that there's a doc fix needed here, if
>> nothing else. The documentation for PQputCopyEnd() clearly implies
>> that if you get a return value of 1, the message is sent, and that's
>> just not true.
>
> That's fair.
Something like the attached?
I don't really know what to say about 0, since it's never actually
returned, so I left that out. But I'm up for suggestions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index e10ccec..d685894 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -5025,12 +5025,12 @@ int PQputCopyEnd(PGconn *conn,
</para>
<para>
- The result is 1 if the termination data was sent, zero if it was
- not sent because the attempt would block (this case is only possible
- if the connection is in nonblocking mode), or -1 if an error
- occurred. (Use <function>PQerrorMessage</function> to retrieve
- details if the return value is -1. If the value is zero, wait for
- write-ready and try again.)
+ The result is 1 if the termination data was sent, or if the socket
+ is in non-blocking mode and the data was queued but could not be sent
+ because the attempt would block. (In non-blocking mode, to be certain
+ that the data has been sent, you should call <function>PQflush</>
+ until it returns zero.) The result is -1 if an error has occurred.
+ (Use <function>PQerrorMessage</function> to retrieve details.)
</para>
<para>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
