summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane2011-12-02 16:33:53 +0000
committerTom Lane2011-12-02 16:34:26 +0000
commitc2e412ad41e24460fa119e4de156b05a21e05433 (patch)
tree7d974e8b960466821e3980be103f10c8aa61495e
parentd08b64581f4a1a65f0fc93b98d7868e7e97038ee (diff)
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.
-rw-r--r--doc/src/sgml/libpq.sgml8
1 files changed, 6 insertions, 2 deletions
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 702ad888f5e..04f0a5876e3 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>