From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "Andrew Chernow" <achernow(at)esilo(dot)com> |
Subject: | Re: pgparam extension to the libpq api |
Date: | 2007-08-17 18:11:08 |
Message-ID: | b42b73150708171111mbdd47e4m47a1b717e72784b1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On 8/17/07, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Attached are some new functions that extend the libpq api to make
after sending the mail, we noticed some dead code that might be
confusing...in PQparamClear there was some legacy code referring to
'slab' which has no effect...ignore. Also slab and slabsize members
of PGparam are not supposed to be there.
> * The synchronous execution functions (for example PQparamExec), takes
>a pointer to a result and return error status, which is _not_ how the
>other flavors of Exec operate, but is very convenient however. If you
>pass in NULL the result is discarded for you. We are stuck on this
>approach, but we like it.
Also, we are _not_ stuck in the **PGresult concept :-). (typo)
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-08-17 19:15:58 | A small rant about coding style for backend functions |
Previous Message | Dave Page | 2007-08-17 18:01:33 | Re: [HACKERS] Re: cvsweb busted (was Re: pgsql: Repair problems occurring when multiple RI updates have to be) |
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2007-08-18 14:46:53 | Re: pgparam extension to the libpq api |
Previous Message | Merlin Moncure | 2007-08-17 17:55:00 | pgparam extension to the libpq api |