From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 2 Dec 2011 16:33:53 +0000 (-0500)
Subject: Add some weasel wording about threaded usage of PGresults.
X-Git-Tag: REL8_4_10~1
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=c2e412ad41e24460fa119e4de156b05a21e05433;p=postgresql

Add some weasel wording about threaded usage of PGresults.

PGresults used to be read-only from the application's viewpoint, but now
that we've exposed various functions that allow modification of a PGresult,
that sweeping statement is no longer accurate.  Noted by Dmitriy Igrishin.
---

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 702ad888f5..04f0a5876e 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -6607,8 +6607,12 @@ myEventProc(PGEventId evtId, void *evtInfo, void *passThrough)
   </para>
 
   <para>
-   <structname>PGresult</> objects are read-only after creation, and so
-   can be passed around freely between threads.
+   <structname>PGresult</> objects are normally read-only after creation,
+   and so can be passed around freely between threads.  However, if you use
+   any of the <structname>PGresult</>-modifying functions described in
+   <xref linkend="libpq-misc"> or <xref linkend="libpq-events">, it's up
+   to you to avoid concurrent operations on the same <structname>PGresult</>,
+   too.
   </para>
 
   <para>