[Pypgsql-checkins] CVS: pypgsql Announce,1.10,1.11 ChangeLog,1.10,1.11 MANIFEST,1.5,1.6 README,1.11,1.12 setup.py,1.10,1.11

[Billy G. A. <bal...@us...>]

Update of /cvsroot/pypgsql/pypgsql
In directory usw-pr-cvs1:/tmp/cvs-serv11404

Modified Files:
	Announce ChangeLog MANIFEST README setup.py 
Log Message:
19SEP2001 bga	Modified these files to get ready for Release 1.6.


Index: Announce
===================================================================
RCS file: /cvsroot/pypgsql/pypgsql/Announce,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** Announce	2001/08/30 01:57:29	1.10
--- Announce	2001/09/20 03:52:32	1.11
***************
*** 1,9 ****
! Announce: pyPgSQL - Version 1.5 is released.
  ===========================================================================
  
  
! 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.
--- 1,11 ----
! 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.
***************
*** 16,20 ****
  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
--- 18,22 ----
  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
***************
*** 23,40 ****
  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.
  
  ---------------------------------------------------------------------------
--- 25,42 ----
  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.
  
  ---------------------------------------------------------------------------
***************
*** 42,79 ****
  ===========================================================================
  
! 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.
--- 44,202 ----
  ===========================================================================
  
! Changes since pyPgSQL Version 1.5.1
! ===================================
  
! The following regression test cases have been added.  These tests are
! 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
! -------------------
!  *  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
+ ------------------------
+  *  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
+ -------------------------
+  *  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.
+ 
+  *  Modified pgFixEsc so that any escaped sequence (\xHH) whose value is
+     greater than 127 is replaced by the actual character.  This works
+     around an apparent problem in PostgreSQL involving encodings.  [Bug
+     #455514]
+ 
+  *  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.
! 

Index: ChangeLog
===================================================================
RCS file: /cvsroot/pypgsql/pypgsql/ChangeLog,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** ChangeLog	2001/08/30 01:57:29	1.10
--- ChangeLog	2001/09/20 03:52:32	1.11
***************
*** 1,4 ****
--- 1,161 ----
  #ident "$Id$"
  
+ Changes since pyPgSQL Version 1.5.1
+ ===================================
+ 
+ The following regression test cases have been added.  These tests are
+ 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
+ -------------------
+  *  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
+ ------------------------
+  *  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
+ -------------------------
+  *  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.
+ 
+  *  Modified pgFixEsc so that any escaped sequence (\xHH) whose value is
+     greater than 127 is replaced by the actual character.  This works
+     around an apparent problem in PostgreSQL involving encodings.  [Bug
+     #455514]
+ 
+  *  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.
+ 
  Changes since pyPgSQL Version 1.5
  =================================

Index: MANIFEST
===================================================================
RCS file: /cvsroot/pypgsql/pypgsql/MANIFEST,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** MANIFEST	2001/08/24 22:26:00	1.5
--- MANIFEST	2001/09/20 03:52:32	1.6
***************
*** 30,33 ****
--- 30,36 ----
  examples/demo2b.py
  test/PgSQLTestCases.py
+ test/regression/pgresult.py
+ test/regression/pgversion.py
+ windows/llsupport.h
  windows/strtok.c
  windows/strtoll.c

Index: README
===================================================================
RCS file: /cvsroot/pypgsql/pypgsql/README,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** README	2001/08/25 16:41:26	1.11
--- README	2001/09/20 03:52:32	1.12
***************
*** 6,10 ****
  ===============================
  
!     pyPgSQL, version 1.5
      A Python DB-API 2.0 compliant interface for PostgreSQL
      Copyright 2000 by Billy G. Allie.
--- 6,10 ----
  ===============================
  
!     pyPgSQL, version 1.6
      A Python DB-API 2.0 compliant interface for PostgreSQL
      Copyright 2000 by Billy G. Allie.
***************
*** 33,64 ****
  ----------------
  
! 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.
  
  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.  This version works
! with PostgreSQL 6.5.2 or later and Python 2.0 or later.
  
! pyPgSQL was developed on a UnixWare 7.1.1 system and tested on both
! UnixWare and RedHat Linux.
  
  1.2 Distribution Files
--- 33,63 ----
  ----------------
  
! 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 language. 
! 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.
  
  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 com-
! piled 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.  This version works with PostgreSQL 6.5.2 or later
! and Python 2.0 or later.
  
! pyPgSQL was developed on a UnixWare 7.1.1 system and tested on both UnixWare
! and RedHat Linux.
  
  1.2 Distribution Files
***************
*** 96,99 ****
--- 95,99 ----
      test/PgSQLTestCases.py - A set of functional test cases built using the 
  			  Python Unit Testing Framework (pyunit)
+     test/regression/*   - Test cases to test specific object in pyPgSQL.
      examples/demo1a.py	- Some example programs using libpq and PgSQL
      examples/demo1b.py
***************
*** 105,117 ****
  ----------------
  
! These instructions assume you have Python 1.6 (or later) and PostgreSQL
! 7.0 (7.1.x recommended) installed on your system.  If you are going to use
! the DB-API 2.0 compliant module, you must also install the mxDateTime module
! from http://starship.python.net/~lemburg/mxDateTime.html.
  
  a.  Download pyPgSQL files if you haven't already done so.
  
! b.  Edit the setup.py file to reflect the your environment.  The setup.py
!     file contains comments to guide you in customizing this file.
  
  c.  Execute "python setup.py build" to build the extension module.
--- 105,117 ----
  ----------------
  
! These instructions assume you have Python 2.0 (or later) and PostgreSQL 7.0
! (7.1.x recommended) installed on your system.  If you are going to use the
! DB-API 2.0 compliant module, you must also install the mxDateTime module from
! http://starship.python.net/~lemburg/mxDateTime.html.
  
  a.  Download pyPgSQL files if you haven't already done so.
  
! b.  Edit the setup.py file to reflect the your environment.  The setup.py file
!     contains comments to guide you in customizing this file.
  
  c.  Execute "python setup.py build" to build the extension module.
***************
*** 121,128 ****
  	   local system administrator.
  
! Note: To build pyPgSQL to work with PostgreSQL 6.5.x (I highly recommend
!       that you upgrade your PostgreSQL to the latest version) you must
!       arrange for the macro 'PGSQL_6X' to be defined when you compile the
!       C code.
  
  1.3.1 Platform specific notes
--- 121,127 ----
  	   local system administrator.
  
! Note: To build pyPgSQL to work with PostgreSQL 6.5.x (I highly recommend that
!       you upgrade your PostgreSQL to the latest version) you must arrange for
!       the macro 'PGSQL_6X' to be defined when you compile the C code.
  
  1.3.1 Platform specific notes
***************
*** 131,152 ****
  Windows: (Thanks to Gerhard Haering <ge...@bi...> for this information)
  
!     To compile the C sources, you'll need a compiler that supports the
!     "long long" type. Microsoft Visual C++ doesn't work for this reason.
!     The GNU compilers are known to work.
  
!     "python setup.py --compiler=mingw32" will build with the native win32
!     mode of the GNU compiler.
  
!     Current versions of the GNU tools on Windows don't include the
!     functions strtoll, strtoull and strtok_r. You'll need these to compile
!     successfully.  strtok.c and modified (to compile under the cygwin)
!     versions of strtoll.c and strtoull.c from the FreeBSD CVS have been
!     added to the pyPgSQL source tree.  You can download the original files
!     from the following URL:
  
  	http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/
  
!     To successfully compile on Windows, you'll need a fairly recent
!     PostgreSQL version: version 7.1.2 plus the update for the file
      src/interfaces/libpq/libpqdll.def from CVS.
  
--- 130,150 ----
  Windows: (Thanks to Gerhard Haering <ge...@bi...> for this information)
  
!     To compile the C sources, you'll need a compiler that supports the "long
!     long" type. Microsoft Visual C++ doesn't work for this reason.  The GNU
!     compilers are known to work.
  
!     "python setup.py --compiler=mingw32" will build with the native win32 mode
!     of the GNU compiler.
  
!     Current versions of the GNU tools on Windows don't include the functions
!     strtoll, strtoull and strtok_r. You'll need these to compile successfully. 
!     strtok.c and modified (to compile under the cygwin) versions of strtoll.c
!     and strtoull.c from the FreeBSD CVS have been added to the pyPgSQL source
!     tree.  You can download the original files from the following URL:
  
  	http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/
  
!     To successfully compile on Windows, you'll need a fairly recent PostgreSQL
!     version: version 7.1.2 plus the update for the file
      src/interfaces/libpq/libpqdll.def from CVS.
  
***************
*** 165,176 ****
  
  If the test cases run without any failures, then you can be reasonably sure
! that the module built correctly.  Please note that the current test cases
! are not complete, but this will change over time.
  
! If you do not wish to install pgunit, run the demo1a.py and demo1b.py
! programs in the examples directory.  Both demo1a.py and demo1b.py print the
! contents of the pg_database table from the template1 database.  Demo1a.py
! was written to use the libpq module, while demo1b.py was written to use the
! PgSQL module.
  
  1.5 Addition information about ...
--- 163,173 ----
  
  If the test cases run without any failures, then you can be reasonably sure
! that the module built correctly.  Please note that the current test cases are
! not complete, but this will change over time.
  
! If you do not wish to install pgunit, run the demo1a.py and demo1b.py programs
! in the examples directory.  Both demo1a.py and demo1b.py print the contents of
! the pg_database table from the template1 database.  Demo1a.py was written to
! use the libpq module, while demo1b.py was written to use the PgSQL module.
  
  1.5 Addition information about ...
***************
*** 196,204 ****
      PgResults	  - handles the query results.
      PgLargeObject - handles the access to PostgreSQL large objects.
!     PgNotify	  - the notify class.  It contains information about a no-
! 		    tification event sent from a PostgreSQL backend process.
!     PgVersion	  - the version class.  It contains information about the
! 		    version of the PostgreSQL backend that a connection object
! 		    is connected to.
  
  The module makes error information available via the following exception
--- 193,201 ----
      PgResults	  - handles the query results.
      PgLargeObject - handles the access to PostgreSQL large objects.
!     PgNotify	  - the notify class.  It contains information about a notifi-
! 		    cation event sent from a PostgreSQL backend process.
!     PgVersion	  - the version class.  It contains information about the ver-
! 		    sion of the PostgreSQL backend that a connection object is
! 		    connected to.
  
  The module makes error information available via the following exception
***************
*** 208,213 ****
      IntegrityError, InternalError, ProgrammingError, NotSupportedError
  
! Additional information about these exceptions can be found in the Python
! DB-API 2.0 documentation.
  
  The following methods are defined by libpq:
--- 205,210 ----
      IntegrityError, InternalError, ProgrammingError, NotSupportedError
  
! Additional information about these exceptions can be found in the Python DB-API
! 2.0 documentation.
  
  The following methods are defined by libpq:
***************
*** 226,234 ****
      PgInt8              - creates a PgInt8 object from a string or number.
  
! There are a number of constants defined in libpq.  They are intended to be
! used as parameters for method calls and to compare against certain results
! generated by method calls.  You should refer to the libpq section of the
! PostgreSQL programmer's manual for information about them.  These constants
! are:
  
      Connection related constants:
--- 223,230 ----
      PgInt8              - creates a PgInt8 object from a string or number.
  
! There are a number of constants defined in libpq.  They are intended to be used
! as parameters for method calls and to compare against certain results generated
! by method calls.  You should refer to the libpq section of the PostgreSQL pro-
! grammer's manual for information about them.  These constants are:
  
      Connection related constants:
***************
*** 815,818 ****
--- 811,815 ----
  			tuple data, 0 if it contains ASCII data. It returns
  			the output of the PQbinaryTuples function call.
+ 			Note: Binary portals are not supported at this time.
      cmdStatus	      - The command status string from the SQL command that
  			generated the PGresult.  It returns the output to the
***************
*** 821,826 ****
  			returns the output of the PQcmdTuples function.
      oidValue	      - The object id of the tuple inserted, if the SQL com-
!     (7.x and above)	mand was an INSERT. Otherwise, contains InvalidOid.
! 			It returns the output of the PQoidValue function.
  
  The PgResult Object has the following methods:
--- 818,823 ----
  			returns the output of the PQcmdTuples function.
      oidValue	      - The object id of the tuple inserted, if the SQL com-
!     (7.x and above)	mand was an INSERT. Otherwise, contains None.  It
! 			returns the output of the PQoidValue function.
  
  The PgResult Object has the following methods:
***************
*** 936,943 ****
  		    ---------------	----------------------
  			PG_BOOL		       PgBoolean
! 			PG_OID		Integer or PgLargeObject
  			PG_INT2		       PgInt2
  			PG_INT4		       Integer
! 			PG_INT8		   PgInt8(1) or Long
  			PG_MONEY	       Float
  			PG_FLOAT4	       Float
--- 933,940 ----
  		    ---------------	----------------------
  			PG_BOOL		       PgBoolean
! 			PG_OID		Integer or PgLargeObject(1)
  			PG_INT2		       PgInt2
  			PG_INT4		       Integer
! 			PG_INT8		   PgInt8(2) or Long
  			PG_MONEY	       Float
  			PG_FLOAT4	       Float
***************
*** 945,949 ****
  		    All Other Types	       String
  
! 		    (1) PgInt8 type is only available on system that have
  			long long (64 bit integer) support.
  
--- 942,949 ----
  		    All Other Types	       String
  
! 		    (1) getvalue() will determine if the OID represents a
! 			PostgreSQL Large Object and returns the appropiate
! 			object.
! 		    (2) PgInt8 type is only available on system that have
  			long long (64 bit integer) support.
  
***************
*** 952,958 ****
  Exceptions:	InterfaceError, TypeError
  
- Note:		getvalue will attempt to determine if a PG_OID type represents
- 		a PgLargeObject, and return the appropriate object.
- 
  2.3.7 getlength
  ---------------
--- 952,955 ----
***************
*** 1012,1034 ****
  The PgLargeObject class provides methods for accessing the PostgreSQL Large 
  Object (LO) system.  It allows access to the LO using Python's File Object
! semantics. The PgLargeObject class defines the following private, read-only
  attributes:
  
-     conn   - The PgConnection object associated with this PgLargeObject.
-     oid    - The OID that identifies this large object to PostgreSQL.
-     fd     - The file descriptor used to read/write to the LO.
-     dirty  - Flag: 1 = data was written to the internal buffer.
-     offset - Offset in the LO where the internal buffer was read from.
-     buffer - Internal buffer used to support readline() calls.
-     size   - Size (length) of the data in the internal buffer.
-     index  - Index into internal buffer where the next byte is read/written.
- 
- and the following public, read-only attributes:
- 
      mode   - The mode used to open the LO
      name   - A string, in the form of "<...>", indicating the source of the LO.
      closed - Flag: 1 = the LO is closed.
  
- 
  and the following public, read-write attribute:
  
--- 1009,1019 ----
  The PgLargeObject class provides methods for accessing the PostgreSQL Large 
  Object (LO) system.  It allows access to the LO using Python's File Object
! semantics. The PgLargeObject class defines the following public, read-only
  attributes:
  
      mode   - The mode used to open the LO
      name   - A string, in the form of "<...>", indicating the source of the LO.
      closed - Flag: 1 = the LO is closed.
  
  and the following public, read-write attribute:
  
***************
*** 1116,1120 ****
  For example, for version 6.5.3, the contents of the PgVersion object would be:
  
!     repr(connection.version)  == "PostgreSQL 6.5.3 on <system dependant info>"
      connection.version.major  == 6
      connection.version.minor  == 5
--- 1101,1105 ----
  For example, for version 6.5.3, the contents of the PgVersion object would be:
  
!     connection.version	      == "PostgreSQL 6.5.3 on <system dependant info>"
      connection.version.major  == 6
      connection.version.minor  == 5
***************
*** 1124,1128 ****
  For example, for version 7.1.1, the contents of PgVer would be:
  
!     repr(connection.version)  == "PostgreSQL 7.1.1 on <system dependant info>"
      connection.version.major  == 7
      connection.version.minor  == 1
--- 1109,1113 ----
  For example, for version 7.1.1, the contents of PgVer would be:
  
!     connection.version        == "PostgreSQL 7.1.1 on <system dependant info>"
      connection.version.major  == 7
      connection.version.minor  == 1
***************
*** 1147,1151 ****
  	connection.version == "7.0.2" will be false.
  	connection.version < "7.0.1" will be false.
! 	connection.version > "7.0.1" will be true.
  
  Note: Both the libpq and PgSQL connection objects have the version attribute.
--- 1132,1136 ----
  	connection.version == "7.0.2" will be false.
  	connection.version < "7.0.1" will be false.
! 	connection.version > "7.1" will be true.
  
  Note: Both the libpq and PgSQL connection objects have the version attribute.
***************
*** 1154,1158 ****
  --------------------
  
! The PgSQL module provide a Python DB=API 2.0 compliant module on top of the
  libpq module.  As the DB-API 2.0 interface is documented elsewhere
  (http://www.python.org/topics/database/DatabaseAPI-2.0.html), I will only
--- 1139,1143 ----
  --------------------
  
! The PgSQL module provide a Python DB-API 2.0 compliant module on top of the
  libpq module.  As the DB-API 2.0 interface is documented elsewhere
  (http://www.python.org/topics/database/DatabaseAPI-2.0.html), I will only
***************
*** 1263,1271 ****
      result set (or nothing).
  
! 3.  When using the execute method, you should only use '%s' [or '%(name)s'] to
!     specify locations where the parameters are to be subsituted, even for
!     integers, floats and other non-string variables.  The execute method will
!     convert all the paramters to a string, applying any quoting that may be
!     necessary before sending the query to the back-end.
  
  4.  The fetchone method will return a PgResultSet object instead of a sequence.
--- 1248,1256 ----
      result set (or nothing).
  
! 3.  When using the execute method, you should only use '%s' [or '%(name)s']
!     (without the quote marks) to specify locations where the parameters are to
!     be subsituted, even for integers, floats and other non-string variables.
!     The execute method will convert all the paramters to a string, applying any
!     quoting that may be necessary before sending the query to the back-end.
  
  4.  The fetchone method will return a PgResultSet object instead of a sequence.
***************
*** 1282,1288 ****
  
  6.  A PostgreSQL specific attribute, named oidValue, was added to the cursor
!     object.  This attribute returns the value of the oidValue attribute of
!     the PgResult object associated with the cursor object and provides a
!     convenient way to get the object ID of a newly inserted record.
  
  3.4 General Notes and Observations
--- 1267,1273 ----
  
  6.  A PostgreSQL specific attribute, named oidValue, was added to the cursor
!     object.  This attribute returns the value of the oidValue attribute of the
!     PgResult object associated with the cursor object and provides a convenient
!     way to get the object ID of a newly inserted record.
  
  3.4 General Notes and Observations
***************
*** 1292,1298 ****
  auto-commit mode unless a transaction is started.  To achive the DB-API 2.0
  mandated behaviour, when connection.autocommit is 0, a transaction is started
! when the first cursor is created for a connection.  After a commit or
! rollback, a new transaction is created on the next call to execute().
  
- When the last opened cursor for a connection is closed, a rollback will occur
- if there is still an open transaction (a commit or rollback wasn't issued)..
--- 1277,1281 ----
  auto-commit mode unless a transaction is started.  To achive the DB-API 2.0
  mandated behaviour, when connection.autocommit is 0, a transaction is started
! when the first cursor is created for a connection.  After a commit or rollback,
! a new transaction is created on the next call to execute().
  

Index: setup.py
===================================================================
RCS file: /cvsroot/pypgsql/pypgsql/setup.py,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** setup.py	2001/09/04 02:28:24	1.10
--- setup.py	2001/09/20 03:52:32	1.11
***************
*** 69,73 ****
  from distutils.extension import Extension
  
! __version__ = "1.5.1"
  
  # Define the runtime library path for this module.  It starts out as None.
--- 69,73 ----
  from distutils.extension import Extension
  
! __version__ = "1.6"
  
  # Define the runtime library path for this module.  It starts out as None.