However, my understanding of the client protocol is that only prepared statements support protocol-level parameters; what is unclear to me at the moment is whether execParams is just a convenient composition of prepare and execPrepared that involves two round trips to the server to excute a query, or if execParams uses a certain trick so that there is only one round trip involved. I figure there is a decent probability of either possibility, though I would definitely favor the latter. I suppose I’ll have to fire up WireShark and/or read the source.

There is one definite disadvantage of execParams, and that is it doesn’t allow multiple SQL statements to be bundled in one request, which is a pretty silly and arbitrary restriction in my opinion. This means that more round-trips are needed in some cases, and that parameter values will have to be sent multiple times in others.

There is a protocol-level trick that you can issue addition requests before the backend finishes responding to the current request, and this trick could be used to reduce the number of round trips. However, libpq does not support this trick, and must finish receiving the response for a given request before it can issue the next one, though perhaps execParams is a special-case of this trick.

And this is the advantage of a native Haskell solution that I was referring to; a native Haskell library can use this trick and, with the careful use of non-strict evaluation, not muck up the interface exposed to the programmer. From the programmers perspective it would still be a bunch of sequential, fully synchronous requests, but the library would be able to issue a few more queries before it has gotten the complete response to the current query. (As long as it has all the results needed to issue the next query, of course.)

Sure, I’d add support for that, though I don’t know when I’d get to it. Offering a patch would likely speed the process…

In HDBC, there’s a parsec parser that replaces ‘?’ with $1, $2, and so on, and uses query parameters in the postgres query. We found that the parser was horribly inefficient, and that it was using a majority of the CPU time and memory allocation in our program. Hopefully yours is a lot faster, since it is written in attoparsec. Have you profiled your parser?

We have no need for the library to replace ‘?’ with $1 for us. We want to be able to write our queries using $-style parameters, but it looks like postgresql-simple does not support that. Would you consider adding it?

I did do a quick-and-dirty editing of mysql-simple’s haddock comments. You should be able to read them yourself if you build the package, or wait for hackage to build the docs for you.

Could you include a small README/docs? You could probably base them off the mysql-simple docs pretty easily.

Hopefully mysql-simple and postgresql-simple will be sufficiently close to each other that moving backends won’t be too difficult, if you’ve paid attention to what database types you use, and steer clear of a lot of useful features, etc.

In the Perl world there is an common database interface module, DBI, that is used to connect to all kinds of databases, using drivers specifically for each, i.e. DBD::Pg, DBD::mysql, DBD::DB2, DBD::Oracle, DBD::SQLite etc. Does a similar Haskell-project exist? It seems that a lot of generic stuff gets duplicated if you need a full database interface module per database (and switching backends become more of a hassle).

Just curious :-)