Re: fixing PQsetvalue()
От | Andrew Chernow |
---|---|
Тема | Re: fixing PQsetvalue() |
Дата | |
Msg-id | 4E033796.3080808@esilo.com обсуждение исходный текст |
Ответ на | Re: fixing PQsetvalue() (Dmitriy Igrishin <dmitigr@gmail.com>) |
Ответы |
Re: fixing PQsetvalue()
Re: fixing PQsetvalue() |
Список | pgsql-hackers |
> 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 callsPQmakeEmptyPGresult. It might be better to say a "server" result vs. a "client" result. Currently, PQsetvalue is broken when provided a "server" generated result. -- Andrew Chernow eSilo, LLC global backup http://www.esilo.com/
В списке pgsql-hackers по дате отправления: