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 21:54:17 |
Message-ID: | BANLkTikdj53urvQV1Y-UqSdf96SoRunyqw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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).
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-06-03 22:21:23 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
Previous Message | Alexander Shulgin | 2011-06-03 21:45:28 | Postmaster holding unlinked files for pg_largeobject table |