Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id 6E558B606AA;
	Thu,  2 Jun 2011 05:29:49 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 34636-03; Thu,  2 Jun 2011 08:29:42 +0000 (UTC)
X-Greylist: delayed 00:05:17.891189 by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-fx0-f46.google.com (mail-fx0-f46.google.com
	[209.85.161.46])
	by mail.postgresql.org (Postfix) with ESMTP id BE663B606A0;
	Thu,  2 Jun 2011 05:29:41 -0300 (ADT)
Received: by fxm17 with SMTP id 17so558736fxm.19
	for <multiple recipients>; Thu, 02 Jun 2011 01:29:41 -0700 (PDT)
Received: by 10.223.70.201 with SMTP id e9mr493085faj.6.1307003063243;
	Thu, 02 Jun 2011 01:24:23 -0700 (PDT)
Received: from [192.168.1.104] (161-32-133-95.pool.ukrtel.net [95.133.32.161])
	by mx.google.com with ESMTPS id a18sm105760fak.29.2011.06.02.01.24.21
	(version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 01:24:22 -0700 (PDT)
Date: Thu, 2 Jun 2011 11:24:18 +0300
From: Pavel Golub <pavel@microolap.com>
Reply-To: Pavel Golub <pavel@gf.microolap.com>
Organization: Microolap
X-Priority: 3 (Normal)
Message-ID: <16110385996.20110602112418@gf.microolap.com>
To: Merlin Moncure <mmoncure@gmail.com>
CC: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	<pgsql-interfaces@postgresql.org>
Subject: Re: [HACKERS] PQdeleteTuple function in libpq
In-Reply-To: <BANLkTim8BxvLLnLL15WjgpVpNX_O0qVAxw@mail.gmail.com>
References: <147534417.20110601184310@gf.microolap.com>
	<BANLkTim8BxvLLnLL15WjgpVpNX_O0qVAxw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201106/2
X-Sequence-Number: 6947

Hello, Merlin.

You wrote:

MM> 2011/6/1 Pavel Golub <pavel@microolap.com>:
>> Hello.
>>
>> I'm some kind of PQdeleteTuple function will be very usefull in libpq.
>> Because right now after deleting some record I need refetch result
>> set, or mark tuple as deleted and this is headache for me.
>>
>> So I checked fe-exec.c sources and wrote this:
>>
>> int PQdeleteTuple(PGresult *src, int tup_num)
>> {
>> =A0 =A0 =A0 =A0if (!src)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL;
>>
>> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0field;
>>
>> =A0 =A0 =A0 =A0/* Invalid tup_num, must be < ntups */
>> =A0 =A0 =A0 =A0if (tup_num < 0 || tup_num >=3D src->ntups)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return FALSE;
>>
>> =A0 =A0 =A0 =A0free(src->tuples[tup_num]);
>>
>> =A0 =A0 =A0 =A0for (i =3D tup_num; i < src->ntups - 1; i++)
>> =A0 =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0src->tuples[i] =3D src->tuples[i + 1];
>> =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0src->ntups--;
>> =A0 =A0 =A0 =A0return TRUE;
>> }
>>
>> But I'm pretty sure, that "free(src->tuples[tup_num])" is bullshit!
>> Because memory is allocated by pqResultAlloc, which in turn plays with
>> memory blocks and so on...
>>
>> Can anyone help me in this?
>>
>> PS I'm not a C guru, so don't please kick me hard. :)

MM> well, you have PQaddTuple, but this was exposed mainly for the purpose
MM> of building a PQresult from outside the libpq library -- not so much
MM> to remove the 'constness' property of the PGResult.  I have no
MM> philosophical objection to making the PGresult able to be manipulated
MM> in that fashion (although others might).

From=20this point of view why we have PQmakeEmptyPGresult, PQcopyResult,
PQsetResultAttrs, PQsetvalue and PQresultAlloc? If we have these
functions I suppose we must have one more to delete (or hide) some
tuples/attributes.

MM>  You could maybe just NULL
MM> out tuples[i] and add some logic to various places to check that, like
MM> in PQgetvalue.

This is what I call headache. In this case to know rows number I
cannot use PQntuples, but need to iterate through all tuples checking
them for NULL or smth.

MM> But before going down that road you need to make the case why this
MM> should be handled in the library and not in your code -- PGresult
MM> memory is slab allocated and therefore can only grow in size -- not
MM> shrink and as such is not so much designed as a general purpose client
MM> side dataset in the high level sense.

Thinking of this I propose to hide tuples and not to eliminate\free
them, because PQclear will free all PGResult resources.

MM> merlin



--=20
With best wishes,
 Pavel                          mailto:pavel@gf.microolap.com