2010/12/6 Andrew Chernow <a...@esilo.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.
