On Sun, Oct 6, 2013 at 12:05 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > The Python bindings for MySQL or PostgreSQL, or even SQLite, are tied to > extension libraries for the specific database engine. > > With SQLite this is not a problem for Python's release management, > because Python's release includes the entire SQLite database engine. > That code is quite small, so this is deemed a good trade. > > With a separately-installed, far more complex database engine like MySQL > or PostgreSQL, the Python bindings will only work if they are compiled > against the correct client library.
Hmm. I see what you mean. Of course, that doesn't bind Python to a specific server version, as one version of the client can talk to any earlier and many later versions of server, but it is an issue. It'd probably be unreasonable to package libpq with Windows installations, but with Linux builds, it should be easy enough to link against whatever libpq happens to be around. If that's unsuited to your server version, it's going to be broken for any other libpq-based apps too. (With package managers like apt, same thing - link against whatever version can be retrieved easily.) The alternative is a pure-Python implementation of the PostgreSQL wire protocol. That would most likely be smaller (if the problem is the size cost of incorporating all of libpq), but would tie Python's pgsql module to a specific protocol version (which doesn't change very often). I don't know if one exists already or not, but it ought to be possible to port the Pike module [1] to Python, if GPL/LGPL/MPL is compatible with the Python licensing. ChrisA [1] http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Sql/pgsql.html -- https://mail.python.org/mailman/listinfo/python-list
