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
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 |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Chernow | 2011-06-02 14:12:40 | Re: PQdeleteTuple function in libpq |
Previous Message | Miguel García | 2011-06-02 13:07:46 |