Announce: pyPgSQL - Version 2.3 beta 1 is released. =========================================================================== pyPgSQL v2.3 beta 1 has been released. It is available at http://pypgsql.sourceforge.net. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, is written in C and exports the PostgreSQL C API to Python. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 7.0 or later and Python 2.0 or later. It was tested with PostgreSQL 7.0.3, 7.1.3, 7.2.2, 7.3 beta 2, Python 2.0.1, 2.1.3 and 2.2.2. Note: It is highly recommended that you use PostgreSQL 7.1 or later and Python 2.1 or later. If you want to use PostgreSQL Large Objects under Python 2.2.x, you *must* use Python 2.2.2, because of a bug in earlier 2.2 versions. Project homepages: pyPgSQL: http://pypgsql.sourceforge.net/ PostgreSQL: http://www.postgresql.org/ Python: http://www.python.org/ This is the first time we release a beta of pyPgSQL. While there didn't change much under the hood, the build process was completely rewritten, so pyPgSQL should now build out of the box on most popular platforms. For you, this means that a "python setup.py build" will now hopefully just work. And for us, this means we'll have to answer less boring support questions :-) These platforms were tested and will build out of the box (of course, more testing won't hurt): UnixWare 7/OpenUNIX 8, Windows native, Cgwin, FreeBSD 4.7, Redhat Linux 7.3, SuSE Linux 7.3, Debian Linux 3.0. The build process is also designed to work with these platforms, but they could not be tested in real life (please do so, if you can!): Mandrake Linux, NetBSD, OpenBSD, MacOS X. If your platform isn't supported out of the box, you can edit a setup.config file to configure the build process. Patches for supporting additional platforms are more than welcome. Look into setup.py for how to do it. The other big change is that Gerhard finally gave up on getting more feedback on his Unicode patch and merged it into the pyPgSQL 2.x line. Hey, if it did work for Linux 2.4, it can work for us, too <0.7 wink>. Using Unicode works like this: from pyPgSQL import PgSQL con = PgSQL.connect(client_encoding=("utf-8", "ignore"), unicode_results=1) # where client_encoding are the parameters you normally give to the encode # method of a Unicode string. unicode_results=1 means pyPgSQL will return # VARCHAR/CHAR/TEXT fields as Unicode strings instead of byte strings. # As I refuse to do any magic, you'll also have to set the client encoding # for the database manually: cursor = con.cursor() cursor.execute("SET CLIENT_ENCODING TO UNICODE") # There are other ways to set the client encoding, including setting a # special environment variable (see PostgreSQL manual), but I recommend # doing it in code. --------------------------------------------------------------------------- ChangeLog: =========================================================================== Changes since pyPgSQL Version 2.2 ================================= The following source code files were added to Version 2.3 beta 1 of pyPgSQL: setup.config - Part of the changed distutils-based build process. If you want to customize the build process (change include and library directories, for example, you only need to edit this file; setup.py should not be edited directly any longer) unicode_tests.py - Test suite for the new Unicode support. Merged from the Unicode patch. Changes to setup.py ------------------- * This file was rewritten entirely so that pyPgSQL now builds out of the box on Windows, Cygwin, Debian Linux, Redhat Linux, SuSE Linux, FreeBSD, UnixWare 7 and OpenUNIX 8. These are the platforms the new build process has been tested on. Untested support is available for Mandrake Linux, NetBSD, OpenBSD and MacOS X. Changes to README ----------------- * Updates for 2.3b1. * Converted the whole document into reStructuredText, so we can easily built a HTML version using docutils (http://docutils.sf.net/). Changes to README.win32 ----------------------- * Remove out of date warning about PostgreSQL on win32 * Reflected change from windows/ to ports/ Changes to PgSQL.py ------------------- * Merged the Unicode patch. pyPgSQL now has full Unicode support. * Added support for the INTERVAL type. * mxDateTime 1.x is no longer supported. Require mxDateTime 2.x and give useful error message if import fails. * Cosmetic changes: use cmp builtin where appropriate. * Fixed typo where PgTypes.__str__ was spelled incorrectly; compare to None using "is" operator. * Take into account that libpq.PgInt8Type might not be available. * Convert ROWID to PgInt8 instead of PgInt4 (the original behaviour led to overflow errors.) * Always set the displaysize field of cursor.description to -1. PostgreSQL 7.3 doesn't provide this information any more and it's pretty useless nowadays that we've mostly left line printers beyond us. Changes to pyPgSQL/__init__.py ------------------------------ * Register libpq.PgInt8 with copy_reg only if available. Changes to pglargeobject.c -------------------------- * Made the 'closed' attribute of PgLargeObject an int instead of a long. Changes to libpqmodule.c: ------------------------- * Fixed the format string of ParseTuple in libPQbool_FromInt. This closes a bug that appeared on Linux/Alpha (#625121). Changes to PgSQLTestcases: -------------------------- * Don't check for the obsolete displaysize field in cursor.description. Also don't check the backend encoding. Multiple files -------------- The windows/ directory has been moved to a port/ directory. Now we *always* use our own version of various string versions instead of special casing for a dozen different Windows and Unix platforms. In order to get the C version of PgInt8Type, it is now required that the constants LLONG_MAX, LLONG_MIN, ULLONG_MAX and ULLONG_MIN are defined when including limits.h and that including Python.h defines HAVE_LONG_LONG. Otherwise, a Python class is used instead.