[ANN] pyPgSQL 2.3 beta 1 released

[Gerhard Häring]

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.