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/