Re: PQdeleteTuple function in libpq

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Pavel Golub <pavel(at)gf(dot)microolap(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: PQdeleteTuple function in libpq
Date: 2011-06-02 13:30:49
Message-ID: BANLkTikCxdeBsEBbWOLQXSkLXnuMRVqPug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

On Thu, Jun 2, 2011 at 3:24 AM, Pavel Golub <pavel(at)microolap(dot)com> wrote:
> 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 this 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.

These functions were basically supported for libpqtypes -- a libpq
wrapping library that needed to be able to construct a result outside
of libpq...libpqtypes uses the result api to expose arrays and
composite types sent over the wire from the server. However, once
generated the result is basically immutable.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-02 13:46:46 Re: Re: patch review : Add ability to constrain backend temporary file space
Previous Message Radosław Smogura 2011-06-02 13:29:02 Re: BLOB support

Browse pgsql-interfaces by date

  From Date Subject
Next Message Andrew Chernow 2011-06-02 14:12:40 Re: PQdeleteTuple function in libpq
Previous Message Miguel Garc&#xED;a 2011-06-02 13:07:46