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
On Mon, Dec 27, 2010 at 4:21 PM, Bruce Momjian br...@momjian.us wrote:
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
to consider libpqtypes for contrib (which we don't have time for atm).
... or as a libpq sibling :)
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves similar to PQexec, but it allows for printf
Am 06.12.10 15:37, schrieb Merlin Moncure:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves
On Mon, Dec 6, 2010 at 9:55 AM, Marc Balmer m...@msys.ch wrote:
Am 06.12.10 15:37, schrieb Merlin Moncure:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
On Mon, Dec 06, 2010 at 10:14:55AM -0500, Merlin Moncure wrote:
On Mon, Dec 6, 2010 at 9:55 AM, Marc Balmer m...@msys.ch wrote:
Am 06.12.10 15:37, schrieb Merlin Moncure:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net
wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer
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
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.
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
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
2010/12/5 Marc Balmer m...@msys.ch:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves similar to PQexec, but it allows for printf style varargs and
does connection re-establishing if the connection fails (it can be
discussed if
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves similar to PQexec, but it allows for printf style varargs and
How is that not a horrible idea, compared to using
On 05.12.2010 12:10, Magnus Hagander wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmerm...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves similar to PQexec, but it allows for printf style varargs and
How is that
Am 05.12.2010 um 11:57 schrieb Heikki Linnakangas
heikki.linnakan...@enterprisedb.com:
On 05.12.2010 12:10, Magnus Hagander wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmerm...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt,
On Sun, Dec 5, 2010 at 11:57, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 05.12.2010 12:10, Magnus Hagander wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmerm...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt,
Hey hackers,
Varargs-exec is useful only when programmer calls it directly.
It is useless when libpq is used to create a more flexible high-level
library (e.g., for C++). PQexecParams (PQexecPrepared) are good
for it.
What about auto reconnect. There are PQreset already and
PG_CONNECTION_OK
On 12/5/2010 4:22 AM, Marc Balmer wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves similar to PQexec, but it allows for printf style varargs and
does connection re-establishing if the connection fails (it can be
discussed if
A varargs version of PQexecParams() would be handy, though. Imagine being able
to do:
PQexecVParams(SELECT * FROM mytable WHERE foo = $1 AND bar = $2, foovar,
barvar);
instead of constructing an array for the variables.
http://libpqtypes.esilo.com/man3/PQexecf.html
--
Andrew Chernow
Hey Andrew,
No, thanks. :-)
And I don't think that libpq should follows it (libpqtypes).
2010/12/6 Andrew Chernow a...@esilo.com
A varargs version of PQexecParams() would be handy, though. Imagine being
able
to do:
PQexecVParams(SELECT * FROM mytable WHERE foo = $1 AND bar = $2, foovar,
20 matches
Mail list logo
