Re: fixing PQsetvalue() - Mailing list pgsql-hackers

From Andrew Chernow
Subject Re: fixing PQsetvalue()
Date
Msg-id 4E033796.3080808@esilo.com
Whole thread Raw
In response to Re: fixing PQsetvalue()  (Dmitriy Igrishin <dmitigr@gmail.com>)
Responses Re: fixing PQsetvalue()
Re: fixing PQsetvalue()
List 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 by date:

Previous
From: Pavel Golub
Date:
Subject: Re: fixing PQsetvalue()
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Make the visibility map crash-safe.