Announcing the release of pyPgSQL 1.6

From: "Billy G(dot) Allie" <Bill(dot)Allie(at)mug(dot)org>
To: pgsql-announce(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org, db-sig(at)python(dot)org
Subject: Announcing the release of pyPgSQL 1.6
Date: 2001-10-04 05:15:15
Message-ID: 200110040515.f945FFZ23428@bajor.mug.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-announce pgsql-interfaces

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

pyPgSQL v1.6 has been released. It is primarily a bug fix release to ver-
sion 1.5.1, but also include some enhancements.

NOTE: This release drops support for PostgreSQL 6.5.x and Python 1.5.x.
If you are still using those versions, you are badly in need of an
upgrade.

It is available at http://sourceforge.net/projects/pypgsql.

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,
exports the PostgreSQL C API to Python. This module is written in C and
can be compiled into Python or can be dynamically loaded on demand. 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.

Note: It is highly recommended that you use PostgreSQL 7.1 or later and
Python 2.1 or later.

PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost all
SQL constructs, including sub-selects, transactions, and user-defined types
and functions. It is the most advanced open-source database available any-
where More information about PostgreSQL can be found at the PostgreSQL home
page at http://www.postgresql.org.

Python is an interpreted, interactive, object-oriented programming lang-
uage. It combines remarkable power with very clear syntax. It has mod-
ules, classes, exceptions, very high level dynamic data types, and dynamic
typing. There are interfaces to many system calls and libraries, as well
as to various windowing systems (X11, Motif, Tk, Mac, MFC). New builtin
modules are easily written in C or C++. Python is also usable as an exten-
sion language for applications that need a programmable interface. Python
is copyrighted but freely usable and distributable, even for commercial
use. More information about Python can be found on the Python home page at
http://www.python.org.

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

Changes since pyPgSQL Version 1.5.1
===================================

The following regression test cases have been added. Each regression test
is designed to rigorously test a specific part of pyPgSQL:

pgresult.py - Test cases for the libpq.PgResult object.
pgversion.py - Test cases for the libpq.PgVersion object.
pgconnection.py - Test cases for the libpq.PgConnection object.

Changes to PgSQL.py
-------------------
* Added support for the PostgreSQL BYTEA type. This will allow binary
values to be stored in the database without the use of Large Objects.

* [Bug #455514, #464213] Changed how strings are escaped/quoted for use as
parameter in queries. Modified code so that array elements are quoted
differently from regular attributes. The repr function is no longer used.

* Changed code so that libpq notices are only converted to Warning exceptions
in certain specific cases. This will prevent Warning exceptions from
occuring when tables with serial fields are created, etc. When Python 2.2
is released, it's Warning framework will be used for libpq notices.

* Cleaned up the logic in hadleArray().

* Updated the PgSQL.__doc__ string.

* [Feature Request #462588] Cursor.close() no longer ends (rollback) the
open transaction when the last cursor is closed.

* On Connection.close(), reset all the attributes to a sane state (i.e.
None or 0, as appropriate).

* [Bug #462589] In a fit of optimization, I had introduced a bug that
caused comparisons of PgResultSets to anything to fail. This bug has
been squashed.

* Fixed several cases of references to non-existing globals in PgMoney.

* Previously, I was not building up the description attribute if no rows
were returned. The description attribute is now built on the first
successful select or cursor fetch.

Changes to libpqmodule.c
------------------------
* [Bug #455514, #464213] Added a new function to escape/quote strings. This
function will escape/quote values used as array elements differently from
regular fields.

* Added a new functions to escape/un-escape strings used as input/output
to/from bytea fields. These function will escape/quote values used as
array elements differently from regular fields.

* Removed code related to PostgreSQL 6.5.x. We now only support
PostgreSQL 7.0 and later.

* Changed 'long long' to 'LONG_LONG'. That way there is no assumption of
how a 64bit integer is declared.

Changes to pgboolean.c
----------------------
* Fix bug in PgBoolean_FromString; also improve and simplify the string
stripping in this method.

Changes to pgconnection.c
-------------------------
* Removed the pgFixEsc() function. It is no longer needed since repr() is
not used to escape/quote strings.

* Changed code so that a PgConnection object's members are set to None if
the finish() method is called.

* Corrected bugs found while developing a set of regression tests for
pgconnection.c.

* Re-ordered the items in PgConnection_members so that the attributes
handled directly by PgConnection_getattr are grouped together and
commented appropriately.

* Removed code related to PostgreSQL 6.5.x. We now only support
PostgreSQL 7.0 and later.

* Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the
object.

Changes to pgint2object.c
-------------------------
* Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the
object.

Changes to pgint8object.c
-------------------------
* Modified code for 64bit (long long) support in the MS Windows
environment with MS Visual C++.

* Made changes to avoid use of long long constants. This was done to
assist in the use of MS Visual C++, which uses something other than LL
to specify long long constants. (It's ugly, I know. Thanks MS.)

* Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the
object.

Changes to pglargeobject.c
--------------------------
* Removed an un-used variable.

* Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the
object.

Changes to pgnotify.c
---------------------
* Clarified an embedded assignment within an if test.

* Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the
object.

Changes to pgresult.c
---------------------
* Removed code related to PostgreSQL 6.5.x. We now only support
PostgreSQL 7.0 and later.

* Fixed a gcc reported int format <-> long int argument mis-match.

* Added check to make sure that the result was from a DQL (Data Query
Language) statement in methods that only make sense for DQL statement
results (fname(), etc.).

* Methods that take field and/or tuple indices will now raise an
exception if those indices are out of range. The previous behavior
was to return the error code from the underlying PostgreSQL C-API
function.

* The fnumber() method will now raise an exception if it is passed a
string that is not a valid column name. The previous behavior was to
return the error code from the PostgreSQL C-API PQfnumber function.

* Correct some incorrect comments.

* Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the
object.

* Added a cache (implemented with a Python Dictionary) for OIDs to hold
the result of the check to see if the OID is a large object. This
should reduce the number queries sent to the database for this
purpose.

* Add code to not check OIDs whose value is less than or equal to 1700
(PG_NUMERIC). These OIDs are not large objects.

Changes to pgversion.c
----------------------
* Removed variables that are no longer needed/referenced.

* Fixed code so that coercion generates an exception if the other object
could not be converted to a PgVersion object.

* Fixed problem where a variable in PgVersion_New() could be used before
it was initialized.

* Improved detection of erroneous input strings.

* Various minor bug fixes and code cleanup.

* Made constructed version string more closely mimic the actual format of
the PostgreSQL version string.

* Having a __dict__ attribute and calling PyMember_Get() in the
PyVersion_getattr function causes dir() to do strange things (like list
members twice). I've removed the __dict__ attribute and added methods
to emulate a mapping object to PgVersion. A PgVersion object will now
act like a dictionary, so use version[key] instead of
version.__dict__[key].

* Make PgVersion_New safe for arbitrary input strings.

* Make the repr method really return the version string.

* Initialize a variable (value) in ver_coerce() to quite an erroneous gcc
warning message.

--
____ | Billy G. Allie | Domain....: Bill(dot)Allie(at)mug(dot)org
| /| | 7436 Hartwell | MSN.......: B_G_Allie(at)email(dot)msn(dot)com
|-/-|----- | Dearborn, MI 48126|
|/ |LLIE | (313) 582-1540 |

Browse pgsql-announce by date

  From Date Subject
Next Message Andrej Falout 2001-10-08 08:01:11 [Announce] Aubit 4gl, Informix-4gl compatible OpenSource GNU compiler project
Previous Message Hans-Juergen Schoenig 2001-09-20 14:54:29 Foundation of a German Speaking User Group

Browse pgsql-interfaces by date

  From Date Subject
Next Message Darko Prenosil 2001-10-04 09:03:16 Re:
Previous Message Dave Harkness 2001-10-03 19:44:17 Re: java.lang.OutOfMemory Exception with a large number