Re: Error in PQsetvalue - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Error in PQsetvalue
Date
Msg-id BANLkTin5i=R1rS0TM6vtrL2fswfQ3-yjUw@mail.gmail.com
Whole thread Raw
In response to Re: Error in PQsetvalue  (Andrew Chernow <ac@esilo.com>)
Responses Re: Error in PQsetvalue
List pgsql-hackers
On Fri, Jun 3, 2011 at 6:22 PM, Andrew Chernow <ac@esilo.com> wrote:
> 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.

Well, that may or not be the case, but that's irrelevant.  This has to
be backpatched to 9.0 and we can't use a bug to sneak in a behavior
change...regardless of what's done, it has to work as documented --
the current behavior isn't broken.  If we want PQsetvalue to support
creating tuples past the insertion point, that should be proposed for
9.2.

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

I disagree -- I think the fix is a one-liner.  line 446:
if (tup_num == res->ntups && !res->tuples[tup_num])

should just become
if (tup_num == res->ntups)

also the memset of the tuple slots when the slot array is expanded can
be removed. (in addition, the array tuple array expansion should
really be abstracted, but that isn't strictly necessary here).

merlin


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [COMMITTERS] pgsql: Disallow SELECT FOR UPDATE/SHARE on sequences.
Next
From: Josh Berkus
Date:
Subject: Re: Remove support for 'userlocks'?