Re: pgparam extension to the libpq api

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, pgsql-patches(at)postgresql(dot)org
Cc: "Andrew Chernow" <achernow(at)esilo(dot)com>
Subject: Re: pgparam extension to the libpq api
Date: 2007-08-18 14:46:53
Message-ID: b42b73150708180746l4ff941f0j7ec9caa7ce4fa520@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
> calling the parameterized interfaces easier, especially when making
> binary calls. IMO, this fills one of the two big missing parts of the
> libpq api when making binary database calls, the other being client
> side handling of complex structures (arrays, etc).

Here is another version of the above with a number of cleanups and fixes.

PGparam version 0.2 (from the fixit.txt):
While enhancing the API and refactoring to match libpq naming, some
bugs were introduced. Below is a list of the fixes. Also, the list
includes a few things that cleaned up the code for readability.

1. PGparam had a slab and slabsize member. This is a dead idea and
was removed. PQparamClear was referencing the slab member; this has
been removed as well.

2. PQparamPutString was accepting a length argument. It specified
the strlen of the string to put. Initially, this API only sent params
in binary format. Because of this, PQparamPutString was not including
the NUL in the value. Since PQparamPutString was changed to send
strings in text format, things broke because there was no NUL.
The length argument has been removed and PQparamPutString properly
handles text format NULL.

3. PQparamPutString has been renamed to PQparamPutText to macth
postgres type.

4. PQparamPutFloat has been renamed to PQparamPutFloat4 to match
postgres type.

4. PQparamPutDouble has been renamed to PQparamPutFloat8 to match
postgres type.

5. PQgetfloat is a macro that did not put "()" around its floatp arg.
was ((void*)flaotp), now its ((void*)(floatp))).

6. PQgetfloat has been renamed to PQgetfloat4 to match postgres type.

7. PQgetdouble has been renamed to PQgetfloat8 to match postgres type.

8. The PARAM_CHKPTR(p) macro was stupidly dereferencing the param
ptr ... ONLY IF IT WAS NULL! Yes, lets make sure the ptr is NULL before
we access it. Cute :)

9. PQgetchar text format was broken (for use with "char" type).
Apparently, when using text format the char value is converted to "A"
instead if "65". Makes sense, just wasn't initially aware of this.

10. PQparamPutChar, PutInt2, PutInt4, PQgetchar, getint2 and getint4 were
all using unsigned types. These have been changed to signed types since
postgres server leans more towards signed types.

11. param.c had a long macro named PARAM_ARRAY_ASSIGN. This has been
converted to a static function named paramArrayAssign().

12. Changes some error messages to make them more clear.

13. Comments were added throughout param.c and result.c.

Attachment Content-Type Size
libpq-param.tar application/x-tar 30.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-08-18 15:47:58 "It'd be better if there were not an implicit cast from int8 to text..."
Previous Message James Mansion 2007-08-18 11:19:26 Re: Another idea for index-only scans

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2007-08-19 16:47:11 Re: [PATCHES] COPYable logs
Previous Message Merlin Moncure 2007-08-17 18:11:08 Re: pgparam extension to the libpq api