Re: Suggesting a libpq addition

2010/12/6 Andrew Chernow <ac(at)esilo(dot)com>

> 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
>
Actually I don't need this functionality :-). I've implemented a library on
C++
which does many things, including auto memory management, type
conversion and binary transfers easy...
But I believe, that including proposed utility functions are better than
printf-like addition... Although, both of these a excess.

> 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.

So, let libpq will not be bloated. Let libpq remain low-level library for
projects like libpqtypes, pqxx and so on (my library too) ;-)

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

--
// Dmitriy.