2011/6/23 Merlin Moncure <mmonc...@gmail.com> > On Jun 6 ( > http://archives.postgresql.org/pgsql-hackers/2011-06/msg00272.php), > Pavel discovered an issue with PQsetvalue that could cause libpq to > wander off into unallocated memory that was present in 9.0.x. A > fairly uninteresting fix was quickly produced, but Tom indicated > during subsequent review that he was not happy with the behavior of > the function. Everyone was busy with the beta wrap at the time so I > didn't press the issue. > > A little history here: PQsetvalue's > (http://www.postgresql.org/docs/9.0/static/libpq-misc.html) main > reason to exist is to allow creating a PGresult out of scratch data on > a result created via PQmakeEmptyResult(). This behavior works as > intended and is not controversial...it was initially done to support > libpqtypes but has apparently found use in other places like ecpg. > > PQsetvalue *also* allows you to mess with results returned by the > server using standard query methods for any tuple, not just the one > 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 > have a window of opportunity to change the behavior here since we know > it isn't being usefully used. I think it's too late for that but it's > if it had to be done the time is now. > > Pavel actually has been requesting to go further with being able to > mess around with PGresults (see: > http://archives.postgresql.org/pgsql-interfaces/2011-06/msg00000.php), > such that the result would start to have some 'recordset' features you > find in various other libraries. Maybe it's not the job of libpq to > do that, but I happen to think it's pretty cool. Anyways, something > has to be done -- I hate to see an unpatched known 9.0 issue remain in > the wild. > +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. > merlin > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- // Dmitriy.
