Re: Error in PQsetvalue

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Pavel Golub <pavel(at)microolap(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Error in PQsetvalue
Date: 2011-06-03 22:22:06
Message-ID: 4DE95E8E.1020808@esilo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/3/2011 5:54 PM, Merlin Moncure wrote:
> On Fri, Jun 3, 2011 at 3:38 PM, Andrew Chernow<ac(at)esilo(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2011-06-03 22:24:28 Re: [HACKERS] Postmaster holding unlinked files for pg_largeobject table
Previous Message Kevin Grittner 2011-06-03 22:21:23 Re: SIREAD lock versus ACCESS EXCLUSIVE lock