| 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: | Whole Thread | Raw Message | 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 |