Skip site navigation (1) Skip section navigation (2)

pyPgSQL - Version 1.5.1 is released.

From: "Billy G(dot) Allie" <bga(at)mug(dot)org>
To: pgsql-announce(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org, db-sig(at)python(dot)org
Subject: pyPgSQL - Version 1.5.1 is released.
Date: 2001-08-31 00:34:10
Message-ID: 200108310034.f7V0YAU24621@bajor.mug.org (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-interfaces
pyPgSQL v1.5.1 has been released.  It is a bug fix release to version 1.5.
It corrects problems with the PgLargeObject.read() method and improves the
stability of pyPgSQL in the MS Windows environment.

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 6.5.2 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
anywhere 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
modules, 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 extension 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
=================================

Compiled the code with options to perform extra syntactic, symantic, and
lint-like checks and corrected any problems that were found.

Changes to pglargeobject.c
--------------------------
 * Why did I introduce a new variable (save) and execute another call to
   lo_tell() when it wasn't needed?  (I have to stop working on code late
   at night. :-)

 * Fixed another bug in PgLo_read().  This one would only rear it's ugly
   head when read() was called with no arguments, and then, only sometimes.
   (I REALLY need to stop working on code late at night [or is that early
   in the morning] :-).

Changes to pgnotify.c
---------------------
 * Changed calls to PyObject_DEL() to  Py_XDECREF() when deleting objects
   embedded in my extension objects.  This corrects a problem expirenced on
   MS Windows.

Changes to pgresult.c
---------------------
 * Part of the logic for building the cursor.desccription attribute retrives
   an OID from the database that is usually zero (0).  This causes a query to
   the database to check to see if the OID represents a large object.  An OID
   of zero can never be a large object, so the code was changed so that when
   the OID is zero, the check to see if it is a large object is skipped.

Changes to setup.py
-------------------
 * Add include_dirs and lib_dirs for building on cygwin.  This change should
   allow pyPgSQL to build 'out of the box' on MS Windows using the cygwin
   environment.

Changes since pyPgSQL Version 1.4
=================================

The code for PgConnection, PgLargeObject, PgNotify, and PgResult was
moved from libpqmodule.c into separate source files.  This was done to 
make it easier to work on the individual pieces of the code.

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

    libpqmodule.h	- This include file brings together all the 
			  various header files needed to build libpqmodule
			  into one place.
    pgconnection.[ch]	- Implements the PgConnection class.
    pglargeobject.[ch]	- Implements the PgLargeObject class.
    pgnotify.[ch]	- Implements the PgNotify class.
    pgresult.[ch]	- Implements the PgResult class.

Also, any constant, read-only attributes in PgConnection, PgLargeObject,
PgNotify, PgResult, and PgVersion are now stored as a Python object instead
of as a native C type.  This was done so that when the attribute is refer-
enced in Python, it does not have to be converted to a Python object.

Changes to PgSQL.py
-------------------
 * Change the code to rollback an open transaction, if any, when the last
   cursor of a connection is closed. [Bug #454653]

 * Added code that will, if weak references are not available, remove any
   cursors that are only referenced from the connection.cursors list.  This
   is in effect garbage collection for deleted cursors.  The garbage col-
   lection of orphaned cursor will occur at the following points:
       1.  After a new cursor is created.
       2.  When a cursor is closed.
       3.  When the connection.autocommit value is changed.

 * Changed cursor.isClosed to cursor.closed.  Why? closed is used in other
   object (file and PgLargeObject, for example) and I thought I would
   follow the trend (i.e. for no good reason).

 * Change from the use of hash() to generate the portal name to the use of
   id().

 * Added code to trap a failure to connect to a database and delete the
   Connection object on failure.  This resolves the problem reported by
   Adam Buraczewski. [Bug #449743]

 * Fixed a bug in fetchmany() that could return more than the requested
   rows if PostgreSQL Portals aren't used in the query.

Changes to libpqmodule.c
------------------------
 * Moved code for PgLargeObject, PgNotify, PgConnection, and PgResult to
   their own files.  This was done to make maintenance easier.

Changes to pgconnection.c
-------------------------
 * Changed how ibuf is defined in pgFixEsc to ensure that the memory pointed
   to by ibuf is allocated from the stack, and thus is writable memory.  The
   way it was defined before could result in the memory being allocated in a
   read-only segment. [Bug #450330]

Changes to pgresult.c
---------------------
 * Changed the return type of result.cmdTuple from a Python String object
   to an Integer object.

 * The code now used pgversion.post70 as a Python Integer.

 * Constant, read-only attributes are now stored as Python objects.  This
   way they do not have to be created each time they are referenced.

Changes to pgversion.c
----------------------
 * Change code to use Py_BuildValue() for creating Python objects from C
   values (where possible).

 * Change attributes that were read-only constants from a C type to a
   Python Object.  This way they don't need to be converted to a Python
   Object each time they are referenced.

 * General code clean up.  Removed some definitions that are in the new
   libpqmodule.h header file.

pgsql-announce by date

Next:From: Tatsuo IshiiDate: 2001-08-31 02:06:00
Subject: Re: Majordomo being upgraded ...
Previous:From: PgSQL Corporate CommunicationsDate: 2001-08-30 19:12:21
Subject:

pgsql-interfaces by date

Next:From: Tatsuo IshiiDate: 2001-08-31 02:06:00
Subject: Re: Majordomo being upgraded ...
Previous:From: Jeremy BuchmannDate: 2001-08-31 00:12:52
Subject: tcl on Mac OS X

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group