Re: fixing PQsetvalue()
От | Dmitriy Igrishin |
---|---|
Тема | Re: fixing PQsetvalue() |
Дата | |
Msg-id | BANLkTimAQSCByZ0Lq-rHPHZFdG+dJEO1mw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fixing PQsetvalue() (Andrew Chernow <ac@esilo.com>) |
Список | pgsql-hackers |
2011/6/23 Andrew Chernow <ac@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.
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.
В списке pgsql-hackers по дате отправления: