Re: Error in PQsetvalue - Mailing list pgsql-hackers

From Andrew Chernow
Subject Re: Error in PQsetvalue
Date
Msg-id 4DE95E8E.1020808@esilo.com
Whole thread Raw
In response to Re: Error in PQsetvalue  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Error in PQsetvalue
List pgsql-hackers
On 6/3/2011 5:54 PM, Merlin Moncure wrote:
> On Fri, Jun 3, 2011 at 3:38 PM, Andrew Chernow<ac@esilo.com>  wrote:
>
>> Eeekks.  Found an additional bug.  PQsetvalue only allocates the actual
>> tuple if the provided tup_num equals the number of tuples (append) and that
>> slot is NULL.  This is wrong.  The original idea behind PQsetvalue was you
>> can add tuples in any order and overwrite existing ones.
>
> That was by design -- you are only supposed to be able to add a tuple
> if you pass in exactly the insertion position (which is the same as
> PQntuples()).  If you pass less than that, you will overwrite the
> value at that position.  If you pass greater, you should get an error.

Actually, the original idea, as I stated UT, was to allow adding tuples 
in any order as well as overwriting them.  Obviously lost that while 
trying to get libpqtypes working, which only appends.

>   This is also how the function is documented.  That's why you don't
> have to zero out the tuple slots at all -- the insertion position is
> always known and you just need to make sure the tuple atts are not
> allocated more than one time per inserted tuple.  Meaning, PQsetvalue
> needs to work more like pqAddTuple (and the insertion code should
> probably be abstracted).
>

You need to have insertion point zero'd in either case.  Look at the 
code.  It only allocates when appending *AND* the tuple at that index is 
NULL.  If pqAddTuple allocated the table, the tuple slots are 
uninitialized memory, thus it is very unlikely that the next tuple slot 
is NULL.

It is trivial to make this work the way it was initially intended (which 
mimics PQgetvalue in that you can fetch values in any order, that was 
the goal).  Are there any preferences?  I plan to supply a patch that 
allows setting values in any order as well as overwriting unless someone 
speaks up.  I fix the docs as well.

-- 
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Next
From: Noah Misch
Date:
Subject: Assert failure when rechecking an exclusion constraint