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.
merlin
