Re: Suggesting a libpq addition

On 12/6/2010 11:40 AM, Dmitriy Igrishin wrote:

IMO, it would be better to implement some utility functions to
make it easy to construct arrays dynamically for PQexecParams
and PQexecPrepared. This seems to me more universal solution
and it is useful for both -- high level libpq-libraries authors and for
those who like to use libpq directly.

Hmm, your idea isn't better, it is identical to what libpqtypes already does :)
http://libpqtypes.esilo.com/browse_source.html?file=exec.c

We wrap PQexecParams and friends.  You are coding libpq.  We extended much effort to provide the same result interface (PGresult), including handling composites and arrays.  You getf composites and arrays as PGresults; where a composite is a single tuple multiple field result, an array is a multiple tuple single field result and composite arrays are multiple tuples and multiple fields.  We've just made a more formal set of utility functions, typically called an API, in an attempt to match the coding standards of the postgresql project.

There is no libpq param interface like results, so we added PGparam stuff. This allows you to pack parameters (PQputf) and than execute it.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/