Re: fixing PQsetvalue()

2011/6/23 Andrew Chernow <ac(at)esilo(dot)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.