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

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 (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-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    |


pgsql-announce by date

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

pgsql-interfaces by date

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

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