Re: PQdeleteTuple function in libpq - Mailing list pgsql-hackers

From Pavel Golub
Subject Re: PQdeleteTuple function in libpq
Date
Msg-id 163769889.20110603085413@gf.microolap.com
Whole thread Raw
In response to Re: PQdeleteTuple function in libpq  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
Hello, Andrew.

You wrote:

AC> On 6/2/2011 11:02 AM, Alvaro Herrera wrote:
>> Excerpts from Andrew Chernow's message of jue jun 02 10:12:40 -0400 2011:
>>
>>>> Andrew, why we have PQmakeEmptyPGresult, PQcopyResult,
>>>> PQsetResultAttrs, PQsetvalue and PQresultAlloc in this case? Of course
>>>> there's no big deal with their absence but let's be consistent.
>>>
>>> I'm not entirely sure what you are trying to do, but can't you use
>>> PQmakeEmptyPGresult, PQsetResultAttrs and PQsetvalue to construct a
>>> result that excludes the tuples you don't want followed by a
>>> PQclear(initial_result)?
>>
>> Seems pretty wasteful if you want to delete a single tuple from a large
>> result.  I think if you desired to compact the result to free some
>> memory after deleting a large fraction of the tuples in the result it
>> could be useful to do that, otherwise just live with the unused holes in
>> the storage area as suggested by Pavel.
>>

AC> Another solution is to manually cursor through the set (like grab 1000
AC> tuples at a time) and copy the set to your own structure.  That way, the
AC> temporary double memory to perform the copy is not as big of a hit.  By
AC> using your own structure, you can organize the memory in a fashion that
AC> is optimized for your requirement.

I agree that there are a lot of possible solutions. But let me compare
my function with official PQsetValue:

1. Both allow changing data in PGresult
2. Both allow changing tuples number
3. Both leave old data untouchable to be eliminated by PQClear
4. PQsetValue allocates more memory during work, mine not (it even may
allow deleted tuple to be reused with a little fix)

So why shouldn't we have both of them to make life easier?

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Estimating total amount of shared memory required by postmaster
Next
From: Peter Eisentraut
Date:
Subject: Re: storing TZ along timestamps