My apologies for the late reply...
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I'd like to see a new variant on PQexec():
PGresult * PQexecf(PGconn *conn, const char *fmt, ...);
Way too late for 8.3 --- if we were going to do something like this,
we should think first and program
While cleaning up some pg_migrator code
(http://pgfoundry.org/projects/pg-migrator/) it occurred to me that a
typical libpq client application spends a lot of code constructing SQL
commands. The code typically looks like this:
a) allocate enough room to hold the command
b)
[EMAIL PROTECTED] writes:
I'd like to see a new variant on PQexec():
PGresult * PQexecf(PGconn *conn, const char *fmt, ...);
Way too late for 8.3 --- if we were going to do something like this,
we should think first and program later. In particular, blindly
adopting the sprintf format
Hm, my first thought was that you should just be using bind parameters instead
of interpolating variables directly into the query.
But the more I think about it the more I like your idea. It's true that using
parameters takes away most of the use cases for the kind of interface you
suggest. But
