[ANN] pyPgSQL 2.3 released

[Yes, I know this announcement is going out a week late]

Announce: pyPgSQL - Version 2.3 is released.
===========================================================================

pyPgSQL v2.3 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, Python 2.0.1, 2.1.3
and 2.2.2.

Note: It is highly recommended that you use PostgreSQL 7.2 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/

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.py 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.

Support for reference cursors was added. Since PostgreSQL 7.2, you could
create cursors in PL/pgSQL and pass a reference to the open cursor back to
the client. PgSQL will now cast those referenced cursors into a Cursor
object that can be used to fetch the results in the cursor. For example
(assuming that mmYearInfo() returns a reference curosr):

$ python
Python 2.2.2 (#7, Nov 27 2002, 17:10:05) [C] on openunix8
Type "help", "copyright", "credits" or "license" for more information.
>>> from pyPgSQL import PgSQL
>>> cx = PgSQL.connect(database='esi')
>>> cu = cx.cursor()
>>> cu.callproc('mmYearInfo')
>>> rs = cu.fetchone()
>>> rs
[<pyPgSQL.PgSQL.Cursor instance at 0x818495c>]
>>> c = rs[0]
>>> for i in c.description:
... print i
...
['model_year', varchar, 4, 8, None, None, None, 0]
['mktg_div_name', varchar, 50, 54, None, None, None, 0]
['model_desc', varchar, 50, 54, None, None, None, 0]
['book_types', varchar, 50, 54, None, None, None, 0]
['vehicle_syskey', integer, 4, 4, None, None, None, 0]
>>> r = c.fetchone()
>>> r
['2003', 'Buick', 'Century', '1;8;9', 2211]
>>>

---------------------------------------------------------------------------
ChangeLog:
===========================================================================

Changes since pyPgSQL Version 2.2
=================================

The following source code files were added to Version 2.3 of pyPgSQL:

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.3.
* 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
-------------------
* Fixed various problems with the PgNumeric constructor and formatting
routines.
* Fixed problems with new __setupTransaction function: |
1. Made it a method of Connection, not Cursor.
2. inTransaction was only set if TransactionLevel was set.
* Fixed instances where method name was incorrect:
Connection__gcCursor -> _Connection__gcCursor
Connection__closeCursor -> _Connection__closeCursor
* Cleaned up code where there was unneeded references to conn in Connection
class. |
* Handle the new '__quote__' method for arrays, too.
* Still handle '_quote' methods for backwards compatibility.
* Fixed changed PG_TIMESTAMP oid, added PG_TIMESTAMPTZ and PG_REFCURSOR oids.
* Reference cursors are now type-casted into cursor objects.
* Completed the emulation of a String object for the PgBytea and PgOther
classes. This corrects several problems with PgBytea concerning compari-
sons, using PgBytea types as keys in dictionaries, etc.
* Added the __hash__ function to the PgNumeric class. Cleaned up the code
in PgNumeric class and made some small improvments to it.
* Added the PgArray class. This is a wrapper around a Python list and is
used for all PostgreSQL arrays. This change was made so that lists and
tuples no longer have a special meaning in the Cursor.execute() method.
* Changed the quoting methods defined in the various classes defining
PostgreSQL support types to __quote__.
* 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 changed PG_TIMESTAMP oid, added PG_TIMESTAMPTZ and PG_REFCURSOR
oids. [Bug #845360]
* Fixed the format string of ParseTuple in libPQbool_FromInt.
This closes a bug that appeared on Linux/Alpha (#625121).

Changes to pgversion.c:
-----------------------
* Changed pgversion to recognize release canidate versions of PostgreSQL.

Changes to PgSQL test cases:
----------------------------
* Updated test cases to allow for changes in PostgreSQL 7.3.
* 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.