Hello, Merlin. I hope it's OK that I've added Andrew's patch to CommitFest: https://commitfest.postgresql.org/action/patch_view?id=606
I did this becuase beta3 already released, but nut nothig is done on this bug. You wrote: MM> On Thu, Jun 23, 2011 at 7:54 AM, Andrew Chernow <a...@esilo.com> wrote: >>> 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. MM> er, right-- the divergence was in how the tuples were getting added -- MM> thanks for the clarification. essentially your attached patch fixes MM> that divergence. MM> merlin -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
