Re: Error in PQsetvalue

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andrew Chernow <ac(at)esilo(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 23:14:09
Message-ID: BANLkTin5i=R1rS0TM6vtrL2fswfQ3-yjUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 3, 2011 at 6:22 PM, Andrew Chernow <ac(at)esilo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2011-06-03 23:41:04 Re: Remove support for 'userlocks'?
Previous Message Tatsuo Ishii 2011-06-03 22:58:50 Re: [COMMITTERS] pgsql: Disallow SELECT FOR UPDATE/SHARE on sequences.