you are creating as you iterate through. This behavior was unnecessary in terms of what libpqtypes and friends needed and may (as Tom suggested) come back to bite us at some point. As it turns out, PQsetvalue's operation on results that weren't created via PQmakeEmptyResult was totally busted because of the bug, so we have a unique opportunity to tinker with libpq here: you could argue that you
+1
Exactly at this moment I am thinking about using modifiable (via PQsetvalue) PGresult instead of std::map in my C++ library for store parameters for binding to executing command. I am already designed how to implement it, and I supposed that PQsetvalue is intended to work with any PGresult and not only with those which has been created via PQmakeEmptyResult... So, I am absolutely sure, that PQsetvalue should works with any PGresult.
All PGresults are created via PQmakeEmptyPGresult, including libpqtypes. Actually, libpqtypes calls PQcopyResult which calls PQmakeEmptyPGresult.
It might be better to say a "server" result vs. a "client" result. Currently, PQsetvalue is broken when provided a "server" generated result.
Yeah, yeah. Thanks for clarification! I am not libpq hacker, just user. So I was thinking that server-returned result creating by libpq's private functions, rather than public PQmakeEmptyPGresult...
-1 although if this feature (which I personally thought already exists according to the documentation) make future optimizations impossible or hard (as mentioned by Tom). Otherwise - +1.
