Re: fixing PQsetvalue()

From: Pavel Golub <pavel(at)microolap(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavel Golub <pavel(at)microolap(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: fixing PQsetvalue()
Date: 2011-07-06 07:53:46
Message-ID: 1453239697.20110706105346@gf.microolap.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

Any news on these issues? Becuase beta3 is scheduled for July 11th...

You wrote:

MM> On Jun 6
MM> (http://archives.postgresql.org/pgsql-hackers/2011-06/msg00272.php)
MM> Pavel discovered an issue with PQsetvalue that could cause libpq to
MM> wander off into unallocated memory that was present in 9.0.x. A
MM> fairly uninteresting fix was quickly produced, but Tom indicated
MM> during subsequent review that he was not happy with the behavior of
MM> the function. Everyone was busy with the beta wrap at the time so I
MM> didn't press the issue.

MM> A little history here: PQsetvalue's
MM> (http://www.postgresql.org/docs/9.0/static/libpq-misc.html) main
MM> reason to exist is to allow creating a PGresult out of scratch data on
MM> a result created via PQmakeEmptyResult(). This behavior works as
MM> intended and is not controversial...it was initially done to support
MM> libpqtypes but has apparently found use in other places like ecpg.

MM> PQsetvalue *also* allows you to mess with results returned by the
MM> server using standard query methods for any tuple, not just the one
MM> you are creating as you iterate through. This behavior was
MM> unnecessary in terms of what libpqtypes and friends needed and may (as
MM> Tom suggested) come back to bite us at some point. As it turns out,
MM> PQsetvalue's operation on results that weren't created via
MM> PQmakeEmptyResult was totally busted because of the bug, so we have a
MM> unique opportunity to tinker with libpq here: you could argue that you
MM> have a window of opportunity to change the behavior here since we know
MM> it isn't being usefully used. I think it's too late for that but it's
MM> if it had to be done the time is now.

MM> Pavel actually has been requesting to go further with being able to
MM> mess around with PGresults (see:
MM> http://archives.postgresql.org/pgsql-interfaces/2011-06/msg00000.php)
MM> such that the result would start to have some 'recordset' features you
MM> find in various other libraries. Maybe it's not the job of libpq to
MM> do that, but I happen to think it's pretty cool. Anyways, something
MM> has to be done -- I hate to see an unpatched known 9.0 issue remain in
MM> the wild.

MM> merlin

--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-07-06 08:32:13 Re: Cascade replication
Previous Message Albe Laurenz 2011-07-06 07:21:31 Re: Small documentation issue