>Any other suggestions before I turn the above into a roadmap page on the
>wiki?
I got sick of the constant stream of escaping bugs impacting on psycopg
and pyPgSQL, and wrote my own DB-API driver, using the more modern
libpq/binary/protocol 3 APIs where ever possible. The result is BSD
licensed:
http://code.google.com/p/ocpgdb/
As well as using the newer APIs, I have attempted to keep the code as
simple as possible, eschewing things like threading as adding too much
complexity for too little gain (particularly true of Python threading),
and I kept to just the code DB-API functionality.
The C code exists mainly to present a pythonic view of libpq. I found
that type conversion and marshalling could generally be done from python
with more than acceptable performance (via the C-coded "struct" module
in the standard library for common types). In my tests, ocpgdb has
performed at least as well as pyPgSQL and psycopg, often a lot better,
primarily due to the use of the libpq binary protocols, I think.
I'm not proposing my module as your canonical implementation, although
you're welcome to it if you like. Rather, it demonstrates another viable
approach, minimal, and using newer libpq APIs.
BTW, with respect to the discussion of the Python DB-API - I see it as
specifying a lowest-common-denominator, or the subset of functionality
that should be available from most databases without requiring
contortions. Like eating at McDonalds, it does the job, but it's never
going to delight or surprise. A PostGreSQL blessed adapter really should
provide access to all the features in libpq, and I'm not sure this is
directly compatible with DBAPI. Instead, the DBAPI-compliance should be
layered on top.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/