Re: Suggesting a libpq addition

On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Sun, Dec 5, 2010 at 10:22, Marc Balmer <marc(at)msys(dot)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 PQexecParams()? You
> have to remember to do all your escaping and things manually, whereas
> PQexecParams() does it automatically.

It's only horrible if you stick to printf style formatting and you are
using sting techniques to inject parameters into the query. Non
parameterized queries should obviously be discouraged. However, it's
entirely possible to wrap the parameterized interfaces with vararg
interface (I should know, because we did exactly that) :-). This
gives you the best of both worlds, easy coding without sacrificing
safety. You might not remember the libpqtypes proposal, but libpq was
specifically extended with callbacks so that libpqtypes could exist
after the community determined that libpqtypes was too big of a change
to the libpq library. I think ultimately this should be revisited,
with libpqtypes going in core or something even richer...I've been
thinking for a while that postgres types should be abstracted out of
the backend into a library that both client and server depend on.

With libpqtypes, we decided to use postgres style format markers:
select PQexecf(conn, "select %int4 + %int8", an_int, a_bigint);

Everything is schema qualified, so that user types are supported (of
course, this requires implementing handling on the client).

Data routed through the binary protocol, with all the byte swapping
etc handled by the library. No escaping necessary. We also added
full support for arrays and composites, which are a nightmare to deal
with over straight libpq, and various other niceties like thread safe
error handling.

merlin