Re: fixing PQsetvalue()

2011/6/23 Merlin Moncure <mmoncure(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
// Dmitriy.