ACHTUNG: THE CPDO WIKI IS NOW (AS OF 2011-May-17) MAINTAINED ON A DEDICATED WIKI SITE: http://whiki.wanderinghorse.net/wikis/cpdo/?page=cpdo_skeleton

The file cpdo_skeleton.c contains a non-functional, but compilable, cpdo_driver implementation which can be used to speed up the process of creating new drivers. It contains dummy implementations for all of the API members, ready to be filled out. How much effort that requires (or does not require, in the case of sqlite3) depends on the underlying database access API. As a basis for comparison:

The up-side to the effort put in to the MySQL driver is that we now have more library-level bits which we will almost certainly need for future drivers.

The drivers i "would like to implement" but will probably never get around to doing:

After looking over Postgres' and ocilib's APIs, i believe most of the infrastructure added for MySQL will be useful in binding those (in particular ocilib), and if it is then we can probably refactor a significant fraction of cpdo_mysql5's innards into reusable components for the other drivers.

After more looking over Postgres, i'm starting to think that Postgres' general world view is too different to easily consolidate here. Some of the problem areas i foresee:

The following page has been the basis for most of my thinking on PG: