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.
2010/12/6 Andrew Chernow
<ac@esilo.com>
That would be a *HUGE* piece of software compared the relatively small
thing I am suggesting...
Sometimes complex and large solutions are required for the simplest of ideas. I believe this is one of those cases. You can't solve the "printf style PQexec" properly by merely implementing a sprintf wrapper. As for escaping (or not escaping) of string arguments, that can be seen
as a bug or a feature. I do not wan't automatic escaping of string
arguments in all cases, e.g. I might to construct an SQL statement with
dynamic parts "WHERE xy" or "AND a = b".
hypothetical example:
filter = "WHERE name like 'Balmer%'";
if (sort == SORT_DESC)
sort = " ORDER BY name DESCENDING";
PQvexec(conn, "SELECT name, nr, id FROM address %s%s", filter, sort);
So what I am aiming at right now is a PQvexec() function that basically
has printf() like semantics, but adds an additional token to the format
string (printf uses %s and %b to produce strings.) I am thinking of
adding %S and %B, which produce strings that are escaped.
This suffers from becoming cryptic over time, see Tom Lane's comments back in 2007 on this (http://archives.postgresql.org/pgsql-hackers/2007-12/msg00362.php). libpqtypes uses the human readable %schema.typename (schema is optional) to specify format specifiers. There is no learning curve or ambiguity, if you want a point than use "%point", or "%my_type".... libpqtypes allows you to register aliases (PQregisterSubClasses) so that you can map %text to %s to make it feel more like C..
--
// Dmitriy.