Thread: Documentation and mutating PGresult objects

Documentation and mutating PGresult objects

From
Jeff Davis
Date:
"PGresult objects are read-only after creation, and so can be passed
around freely between threads."

From http://www.postgresql.org/docs/9.1/static/libpq-threading.html

But what about things like PQsetvalue? Is that a documentation bug?
Should result objects be protected by synchronization as well as
connection objects?

Regards,
    Jeff Davis


Re: Documentation and mutating PGresult objects

From
Dmitriy Igrishin
Date:
Hey Jeff,

2012/1/5 Jeff Davis <pgsql@j-davis.com>
"PGresult objects are read-only after creation, and so can be passed
around freely between threads."

From http://www.postgresql.org/docs/9.1/static/libpq-threading.html

But what about things like PQsetvalue? Is that a documentation bug?
Should result objects be protected by synchronization as well as
connection objects?


--
// Dmitriy.


Re: Documentation and mutating PGresult objects

From
Tom Lane
Date:
Jeff Davis <pgsql@j-davis.com> writes:
> "PGresult objects are read-only after creation, and so can be passed
> around freely between threads."
> From http://www.postgresql.org/docs/9.1/static/libpq-threading.html

That's not what it says now.

Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [0de93a9c6] 2011-12-02 11:33:53 -0500
Branch: REL9_1_STABLE [1cd1a7c10] 2011-12-02 11:34:14 -0500
Branch: REL9_0_STABLE [8af71fc56] 2011-12-02 11:34:20 -0500
Branch: REL8_4_STABLE Release: REL8_4_10 [c2e412ad4] 2011-12-02 11:34:26 -0500

    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.

            regards, tom lane