2011/6/23 Andrew Chernow <a...@esilo.com> > 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. > -- > Andrew Chernow > eSilo, LLC > global backup > http://www.esilo.com/ > -- // Dmitriy.
