pypgsql-users — Discussion list for the pyPgSQL user community.

Re: [Pypgsql-users] How important is Python 2.1 compatibility?

[Gerhard <ger...@gm...>]

* Tom Jenkins <tje...@de...> [2002-06-05 23:57 -0400]:
> Well Zope 2.x does not run with python 2.2

Btw. the ZpyPgSQLDA in CVS isn't meant for serious use, yet. It hasn't
been worked on since its initial putting into CVS.

Or is anybody using pyPgSQL itself with Zope?

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] How important is Python 2.1 compatibility?

[Tom J. <tje...@de...>]

Well Zope 2.x does not run with python 2.2

On Thu, 2002-06-06 at 00:00, Billy G. Allie wrote:
> Now that Python 2.2.x has been out for a while, I would like to find out
> how 
> important Python 2.1 compatibility is.  There are a number of new
> features in 
> Python 2.2.x that would make things in pyPgSQL cleaner, easier, etc.,
> but of 
> course using those features would not work with earlier version of
> Python.
> 
> I would like to conduct a poll of the user community to decide on one of
> two 
> courses of action:
> 
> 1.  Should pyPgSQL drop compatibility with versions of Python previous
> to 
> version 2.2?
> 
> 2.  Should we start a new branch that drops compatibility with previous 
> versions and maintain the 2.x branch (bug fixes only) to provide 2.0 and
> 2.1 
> compatibility?
> 
> Personally, I'm in favor of option 1, but I will support whichever
> option is 
> chosen by the user community.
> 
> I look forward to you input.
> -- 
> ____       | Billy G. Allie    | Domain....: Bil...@mu...
> |  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
> |-/-|----- | Dearborn, MI 48126|
> |/  |LLIE  | (313) 582-1540    |
> 
> 
-- 

Tom Jenkins
Development InfoStructure
http://www.devis.com

[Pypgsql-users] How important is Python 2.1 compatibility?

[Billy G. A. <Bil...@mu...>]

Now that Python 2.2.x has been out for a while, I would like to find out how 
important Python 2.1 compatibility is.  There are a number of new features in 
Python 2.2.x that would make things in pyPgSQL cleaner, easier, etc., but of 
course using those features would not work with earlier version of Python.

I would like to conduct a poll of the user community to decide on one of two 
courses of action:

1.  Should pyPgSQL drop compatibility with versions of Python previous to 
version 2.2?

2.  Should we start a new branch that drops compatibility with previous 
versions and maintain the 2.x branch (bug fixes only) to provide 2.0 and 2.1 
compatibility?

Personally, I'm in favor of option 1, but I will support whichever option is 
chosen by the user community.

I look forward to you input.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

[Billy G. A. <Bil...@mu...>]

Gerhard =3D?unknown-8bit?Q?H=3DE4ring?=3D wrote:
> * pa...@bo... <pa...@bo...> [2002-06-05 17:08 -0000]:
> > On Wed, 5 Jun 2002 18:40:11 +0200 Gerhard H=E4ring wrote:
> > >CC-ing to pypgsql-users list, maybe other users have comments on thi=
s issu
> e,
> > >too.
> > =

> > [Arrays vs. 'IN']
> > =

> > >QUERY: DECLARE PgSQL_08120A6C CURSOR FOR select * from cages where n=
ame
> > >       in '{"mammals","apes"}'
> > >
> > >... which obviously cannot work. The reason is that if pyPgSQL encou=
nters a
> > >tuple or a list in the statement parameters, it will quote them suit=
able for
> > >use as an ARRAY. Unfortunately, the ARRAY syntax is different from w=
hat you
> > >would need for the IN operator in SQL.
> > =

> > Right, and there's no way of knowing what the database engine expects=
 for
> > that parameter until it has parsed the statement.
> =

> Unless you also parse at the client side, which I'd rather not ;-)
> =

> There might be a solution with controlling the behaviour using a flag i=
n the
> cursor object, for example.

One solution would be to add a new type called pgArray, which would be a =
simple wrapper to the list type that would provide a quote method for cha=
nging it's list into the proper format needed by PostgreSQL for an array.=
  That would free up the list type so that it can be used as in the given=
 example.  This would mean, though, that you would lose the automatic tra=
nslation of a python list to a PostgreSQL array.  This seems a small pric=
e to pay for the benefit gained.

Python 2.2.x new classes would make this rather easy.
-- =

____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

[Gerhard <ge...@bi...>]

* Gerhard Häring <ger...@gm...> [2002-06-05 19:55 +0200]:
> >>> from pyPgSQL import PgSQL
> >>> conn = PgSQL.connect(client_encoding="utf-8", unicode_results=1)
> >>> cursor = conn.cursor()

Here I missed something that (still) needs to be done explicitely:

cursor.execute("set client_encoding to UNICODE")

> >>> cursor.execute("insert into test(name) values (%s)", unicode("Österreich", "latin1"))
> >>> cursor.execute("select * from test")
> >>> res = cursor.fetchone()
> >>> print repr(res.name)
> u'\xd6sterreich'

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

[Gerhard <ger...@gm...>]

* Gerhard Häring <ger...@gm...> [2002-06-05 18:40 +0200]:
> * Paul Boddie <pa...@bo...> [2002-06-05 08:21 -0700]:
> > [...] Another thing: pyPgSQL seems to be fine with Unicode query strings
> > (unlike psycopg, apparently), but it doesn't like Unicode parameter values.
> > Is there some explicit encoding step I should be performing?
> 
> I've fiddled with adding Unicode support for some time now, but I didn't get
> enough testers yet to make me comfortable enough with it for adding it to a
> pyPgSQL release. On the Sourceforge patches section, I've uploaded a patch
> for full Unicode support, including getting Unicode results back from the
> database, insert Unicode strings, and automatic encoding conversions. I'll
> try to update this patch today to work with the latest pyPgSQL 2.1 release
> and drop you a note when it's ready.

Done now. I like vimdiff :-)

You can get the experimental Unicode patch that applies cleanly to pyPgSQL 2.1
at the following long URL:

http://sf.net/tracker/index.php?func=detail&aid=484468&group_id=16528&atid=316528

There isn't much docs (read: any) yet, but you can look into the Unicode test
suite (test/unicode_tests.py) that the patch will install for usage of the
various Unicode features.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

[Gerhard <ger...@gm...>]

* pa...@bo... <pa...@bo...> [2002-06-05 17:08 -0000]:
> On Wed, 5 Jun 2002 18:40:11 +0200 Gerhard Häring wrote:
> >CC-ing to pypgsql-users list, maybe other users have comments on this issue,
> >too.
> 
> [Arrays vs. 'IN']
> 
> >QUERY: DECLARE PgSQL_08120A6C CURSOR FOR select * from cages where name
> >       in '{"mammals","apes"}'
> >
> >... which obviously cannot work. The reason is that if pyPgSQL encounters a
> >tuple or a list in the statement parameters, it will quote them suitable for
> >use as an ARRAY. Unfortunately, the ARRAY syntax is different from what you
> >would need for the IN operator in SQL.
> 
> Right, and there's no way of knowing what the database engine expects for
> that parameter until it has parsed the statement.

Unless you also parse at the client side, which I'd rather not ;-)

There might be a solution with controlling the behaviour using a flag in the
cursor object, for example.

> I suppose there isn't a way of getting type information from PostgreSQL about
> parameters - indeed, does PostgreSQL actually support parameters in the way
> that other database systems do?

You mean prepared statements? No, PostgreSQL doesn't currently support these.
All it gets is a query string. From what I hear on IRC and on
postgresql-hackers, people are working on prepared statements.

Unfortunately, we'll have a problem with them and pyPgSQL, as as far as I see,
prepared statements don't play nice with the DB-API 2.0 'format' and 'pyformat'
parameter quoting styles. I believe that the 'qmark' or 'numeric' styles are
designed exactly for prepared statement use. It might be possible to rewrite
the query and continue using our 'pyformat' style, but I haven't tried, yet.

> > [Unicode patch] 
> That would be great. Where XML data and PostgreSQL come together, it quickly
> becomes a requirement to handle the data gracefully or transparently,
> although I suspect that many database systems still struggle with Unicode.

Hopefully, pyPgSQL with PostgreSQL works fine. PostgreSQL can even use the
UTF-8 encoding at server side. With the Unicode patch and appropriate
parameters for the connect() call, you should be able to use full Unicode:

>>> from pyPgSQL import PgSQL
>>> conn = PgSQL.connect(client_encoding="utf-8", unicode_results=1)
>>> cursor = conn.cursor()
>>> cursor.execute("insert into test(name) values (%s)", unicode("Österreich", "latin1"))
>>> cursor.execute("select * from test")
>>> res = cursor.fetchone()
>>> print repr(res.name)
u'\xd6sterreich'

Btw. the Unicode support that PySQLite recently gained is based on the same
patch, and it includes an example for mass-importing Freshmeat project data
from XML into a database. As you said, XML is Unicode-based, so this is a
relatively practical example, I hope.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

[Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

[<pa...@bo...>]

On Wed, 5 Jun 2002 18:40:11 +0200 Gerhard Häring <ger...@gm...> wrote:
>CC-ing to pypgsql-users list, maybe other users have comments on this issue,
>too.

[Arrays vs. 'IN']

>QUERY: DECLARE PgSQL_08120A6C CURSOR FOR select * from cages where name
>       in '{"mammals","apes"}'
>
>... which obviously cannot work. The reason is that if pyPgSQL encounters a
>tuple or a list in the statement parameters, it will quote them suitable for
>use as an ARRAY. Unfortunately, the ARRAY syntax is different from what you
>would need for the IN operator in SQL.

Right, and there's no way of knowing what the database engine expects for that 
parameter until it has parsed the statement. I suppose there isn't a way of 
getting type information from PostgreSQL about parameters - indeed, does 
PostgreSQL actually support parameters in the way that other database systems 
do? I got the impression that PostgreSQL database modules have to bundle the 
parameter values into the query as shown above, rather than passing those 
values separately.

>I'm not sure if something can be done about this problem. It seems to me that
>it's an either/or with ARRAY vs. your desired conversion for the IN operator.

That's an unfortunate limitation, but thankfully I didn't need to use 'IN' 
after all. :-)

>I've fiddled with adding Unicode support for some time now, but I didn't get
>enough testers yet to make me comfortable enough with it for adding it to a
>pyPgSQL release. On the Sourceforge patches section, I've uploaded a patch for
>full Unicode support, including getting Unicode results back from the database,
>insert Unicode strings, and automatic encoding conversions. I'll try to update
>this patch today to work with the latest pyPgSQL 2.1 release and drop you a
>note when it's ready.

That would be great. Where XML data and PostgreSQL come together, it quickly 
becomes a requirement to handle the data gracefully or transparently, although 
I suspect that many database systems still struggle with Unicode.

Thanks for the explanation and the great work!

Paul

[Pypgsql-users] Re: [ANN] pyPgSQL 2.1 released

[Gerhard <ger...@gm...>]

CC-ing to pypgsql-users list, maybe other users have comments on this issue,
too.

* Paul Boddie <pa...@bo...> [2002-06-05 08:21 -0700]:
> Gerhard <gh_...@gm...> wrote:
> > 	
> > * Fixed the array parsing so it also works with PostgreSQL versions 7.2.x.
> 
> I doubt that this is related, but does the 'IN' operator work with
> statement parameters (bind variables) in pyPgSQL yet? I recently found
> that doing something like this...
> 
>   cursor.execute("SELECT * FROM CAGES WHERE NAME IN %s",
>     (("mammals", "apes"),))
> 
> ...gives some kind of parsing error inside pyPgSQL.

It is indeed a related issue. If you want to show which queries pyPgSQL
produces, the trick is to access a special attribute like this:

conn.conn.toggleShowQuery

This would show the following query is executed:

QUERY: DECLARE PgSQL_08120A6C CURSOR FOR select * from cages where name in '{"mammals","apes"}'

... which obviously cannot work. The reason is that if pyPgSQL encounters a
tuple or a list in the statement parameters, it will quote them suitable for
use as an ARRAY. Unfortunately, the ARRAY syntax is different from what you
would need for the IN operator in SQL.

I'm not sure if something can be done about this problem. It seems to me that
it's an either/or with ARRAY vs. your desired conversion for the IN operator.

> [...] Another thing: pyPgSQL seems to be fine with Unicode query strings
> (unlike psycopg, apparently), but it doesn't like Unicode parameter values.
> Is there some explicit encoding step I should be performing?

I've fiddled with adding Unicode support for some time now, but I didn't get
enough testers yet to make me comfortable enough with it for adding it to a
pyPgSQL release. On the Sourceforge patches section, I've uploaded a patch for
full Unicode support, including getting Unicode results back from the database,
insert Unicode strings, and automatic encoding conversions. I'll try to update
this patch today to work with the latest pyPgSQL 2.1 release and drop you a
note when it's ready.

Gerhard
-- 
This sig powered by Python!
Außentemperatur in München: 25.7 °C      Wind: 4.5 m/s

[Pypgsql-users] [ANN] pyPgSQL 2.1 released

[Gerhard <ger...@gm...>]

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

pyPgSQL v2.1 has been released. It is a bug fix release to version 2.0, but
also includes some enhancements.

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,
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 2.0
=================================

pyPgSQL 2.1 is now compatible and tested to work with PostgreSQL 7.2.x.

Changes to README
-----------------
* Added documentation for the new TransactionLevel attribute of
the Connection object.

Changes to PgSQL.py
-------------------
* Added code to implement support for setting PostgreSQL transaction
levels. [Feature Request #481727].

* Got rid of redundant building and storing of the
mapping of column names to column positions in the PgResultSet class. Now,
rows of the same query are instances of a dynamically created class, which
has this mapping as a class attribute instead of an attribute of the
instance. This saves a lot of space, and also slightly increases
performance of cursor fetches.
	
* Fixed the array parsing so it also works with PostgreSQL versions 7.2.x.
The PostgreSQL developers changed the quoting in the string representation
of arrays in 7.2 beta cycle: strings are now only quoted when otherwise
the array representation would be ambiguous. The new parseArray() method
should handle the old and new way of quoting in arrays. [Bug #539769].
Also added a new testcase for the ARRAY type.

* Improved the array parsing, so that it now passes all
the new mean testcases. Added support for parsing multidimensional arrays.
Eventually, the array parsing code should go as a support function into
libpq.

* Replaced all typechecks with "is" operators instead
of equals. Mark McEahern had a problem with using pyPgSQL in combination
with a FixedPoint class where the reason was that the FixedPoint class was
not comarable to None. The consensus on python-list was that None and all
types are singletons, so they should be checked using "is", which is also
faster, because it only checks for object identity.

* Fixed a couple of problems found by Steven D. Arnold:
1. A undefined variable was used in a few places where notices were popped
   from the notice list.
2. Comparisons between 2 PgNumerics gave the wrong result.

* Fixed problem that occurs when the sum() aggregate returns a
NULL. [Bug #505162].

Changes to pgversion.c
----------------------
* Allow for development and beta versions of PostgreSQL

Changes to libpqmodule.c
------------------------
* Removed special escaping of control characters in arrays.

* Added support for two missing OID types: aclitem and macaddr. 

* Applied patch by Chris Bainbridge [Patch #505941] "fix for null bytes in
bytea".

Changes to pgresult.c
---------------------
* Change the point at which an OID is tested to see if it is a
Large Object from 1700 to 16383.

Re: [Pypgsql-users] importing libpq

[bob a. <rd...@pa...>]

On Monday, May 27, 2002, at 11:54  AM, Gerhard H=E4ring wrote:

> * bob ackerman <rd...@pa...> [2002-05-25 20:47 -0700]:
>> on openbsd 3.x (how do i find out?)
>
> Perhaps: uname -a

OpenBSD shopip 3.1 GENERIC#59 i386

>> postgresql 7.1.3
>> python 2.2
>> pyPgSQL 2.0
>>
>> i installed it, but when i did 'from pyPgSQL import libpq'
>> python says 'No module libpq'.
>> i can import pyPgSQL and i see libpq in its directory ok.
>
> So pyPgSQL works but you cannot import libpq on its own?

yes, i could do 'from pyPgSQL import PgSQL'.
it is just libpqmodule.so that couldn't be found.

>
>> i got around this by copying libpqmodule.so from there to =
/usr/local/lib
>> where my other libpq thingies are and i can now import libpq.
>
> Even more strange is that this works, as I don't think that
> /usr/local/lib is in sys.path.

you're right. it is not in sys.path.

>
> Could you please post the output of "from pyPgSQL import libpq" in an
> interactive interpreter session when you start Python with "python =
-v"?
> You can use the "script" command for that if you like.

well. that's interesting. i got:
import pyPgSQL.libpq.libpq # dynamically loaded from=20
/usr/local/lib/python2.2/site-packages/pyPgSQL/libpq/libpqmodule.so

so i took it out of /usr/local/lib and of course it still works.
so what the heck. i looks like it was good as is. i don't know why it =
didn'
t find the module yesterday.
so it's: 'never mind'
and thanks.

> Gerhard
> --
> mail:   gerhard <at> bigfoot <dot> de       registered Linux user =
#64239
> web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id =
AD24C930
> public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 =
C930
> reduce(lambda x,y:x+y,map(lambda=20
> x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users
>

Re: [Pypgsql-users] importing libpq

[Gerhard <ger...@gm...>]

* bob ackerman <rd...@pa...> [2002-05-25 20:47 -0700]:
> on openbsd 3.x (how do i find out?)

Perhaps: uname -a

> postgresql 7.1.3
> python 2.2
> pyPgSQL 2.0
> 
> i installed it, but when i did 'from pyPgSQL import libpq'
> python says 'No module libpq'.
> i can import pyPgSQL and i see libpq in its directory ok.

So pyPgSQL works but you cannot import libpq on its own?

> i got around this by copying libpqmodule.so from there to /usr/local/lib 
> where my other libpq thingies are and i can now import libpq.

Even more strange is that this works, as I don't think that
/usr/local/lib is in sys.path.

Could you please post the output of "from pyPgSQL import libpq" in an
interactive interpreter session when you start Python with "python -v"?
You can use the "script" command for that if you like.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

[Pypgsql-users] importing libpq

[bob a. <rd...@pa...>]

on openbsd 3.x (how do i find out?)
postgresql 7.1.3
python 2.2
pyPgSQL 2.0

i installed it, but when i did 'from pyPgSQL import libpq'
python says 'No module libpq'.
i can import pyPgSQL and i see libpq in its directory ok.

i got around this by copying libpqmodule.so from there to /usr/local/lib 
where my other libpq thingies are and i can now import libpq.

but i was wondering what i haven't done correctly.

i don't seem to have a proper lib directory for postgresql - no /usr/local/
lib/pgsql or anysuch.
but that wouldn't affect this. i assume.

just a little wondering/worried

Re: [Pypgsql-users] Unit test script appears to have problems

[Steve W. <ste...@gs...>]

Gerhard H=E4ring wrote:

> I'm not sure where you got that unittest.py from, but it's apparently
> not from pyunit 1.4 (__version__ =3D=3D "1.40"), or Python 2.2.1
> (__version__ =3D=3D "1.14"). Looks like you only need to place the orig=
inal
> Python 2.2.1 unittest.py (is most recent available) there again.

You're right -- I deleted the unittest.py from my site-packages and=20
the one in Python 2.2.1 shows __version__ =3D=3D "1.14" ... now the test=20
script works:

--------------------------------------------------------------------
[waterbug@beeblebrox test]$ python PgSQLTestCases.py=20
............................................F....F.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: Test execute() with a singleton string as the parameter.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "PgSQLTestCases.py", line 494, in CheckExecuteWithSingleton
    "Length of cur.description is %d, it should be %d." %
  File "/usr/local/lib/python2.2/unittest.py", line 286, in failUnlessEqu=
al
    raise self.failureException, \
AssertionError: Length of cur.description is 9, it should be 4.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: MoreResultObjectChecks (__main__.PgSQLTestCases)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "PgSQLTestCases.py", line 680, in MoreResultObjectChecks
    self.fail(msg)
  File "/usr/local/lib/python2.2/unittest.py", line 254, in fail
    raise self.failureException, msg
AssertionError: invalid syntax (line 1)

----------------------------------------------------------------------
Ran 51 tests in 1.046s

FAILED (failures=3D2)
----------------------------------------------------------------------

... which gives the error you said to expect about the length of=20
cur.description ... whew! =20

Sorry for the false alarm!   =20

-- Steve.

Re: [Pypgsql-users] Unit test script appears to have problems

[Gerhard <ger...@gm...>]

* Steve Waterbury <ste...@gs...> [2002-05-20 17:32 -0400]:
> Gerhard Häring wrote:
> > 
> > Really strange. Let's try to find out what happened:
> > 
> > You can start Python with "python -v" and then "import unittest". This
> > should show which unittest.py is really loaded. It should look about
> > like:
> > 
> > >>> import unittest
> > # /usr/local/lib/python2.2/unittest.pyc matches
> > # /usr/local/lib/python2.2/unittest.py
> > [...]
> > 
> > Then you can use "print unittest.__version__" to see the revision number
> > of the module.
> 
> Here's what I get:
> 
> ---------------------------------------------------------------
> 
> [waterbug@beeblebrox pypgsql-2.0]$ python
> Python 2.2.1 (#1, Apr 18 2002, 01:54:11) 
> [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>>    
> [waterbug@beeblebrox pypgsql-2.0]$ python -v
> [...]
> >>> import unittest
> # /usr/local/lib/python2.2/site-packages/unittest.pyc matches /usr/local/lib/python2.2/site-packages/unittest.py
> import unittest # precompiled from /usr/local/lib/python2.2/site-packages/unittest.pyc
> [...]
> >>> print unittest.__version__
> 1.1.1.1

I couldn't find this version in either the pyunit or Python CVS
repositories. You found a very strange version of pyunit somewhere ;-)

> I'm hoping that means they didn't bother to populate __version__
> correctly!  ;^)

I'm not sure where you got that unittest.py from, but it's apparently
not from pyunit 1.4 (__version__ == "1.40"), or Python 2.2.1
(__version__ == "1.14"). Looks like you only need to place the original
Python 2.2.1 unittest.py (is most recent available) there again.

The __version__ thing is indeed confusing, as it depends on wether you
use pyunit from Python or from the pyunit project itself. All it really
marks, however, is the revision number of the file in the respective CVS
repository.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Unit test script appears to have problems

[Steve W. <ste...@gs...>]

Gerhard H=E4ring wrote:
>=20
> Really strange. Let's try to find out what happened:
>=20
> You can start Python with "python -v" and then "import unittest". This
> should show which unittest.py is really loaded. It should look about
> like:
>=20
> >>> import unittest
> # /usr/local/lib/python2.2/unittest.pyc matches
> # /usr/local/lib/python2.2/unittest.py
> [...]
>=20
> Then you can use "print unittest.__version__" to see the revision numbe=
r
> of the module.

Here's what I get:

---------------------------------------------------------------

[waterbug@beeblebrox pypgsql-2.0]$ python
Python 2.2.1 (#1, Apr 18 2002, 01:54:11)=20
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>   =20
[waterbug@beeblebrox pypgsql-2.0]$ python -v
# /usr/local/lib/python2.2/site.pyc matches /usr/local/lib/python2.2/site=
.py
import site # precompiled from /usr/local/lib/python2.2/site.pyc
# /usr/local/lib/python2.2/os.pyc matches /usr/local/lib/python2.2/os.py
import os # precompiled from /usr/local/lib/python2.2/os.pyc
import posix # builtin
# /usr/local/lib/python2.2/posixpath.pyc matches /usr/local/lib/python2.2=
/posixpath.py
import posixpath # precompiled from /usr/local/lib/python2.2/posixpath.py=
c
# /usr/local/lib/python2.2/stat.pyc matches /usr/local/lib/python2.2/stat=
.py
import stat # precompiled from /usr/local/lib/python2.2/stat.pyc
# /usr/local/lib/python2.2/UserDict.pyc matches /usr/local/lib/python2.2/=
UserDict.py
import UserDict # precompiled from /usr/local/lib/python2.2/UserDict.pyc
# /usr/local/lib/python2.2/copy_reg.pyc matches /usr/local/lib/python2.2/=
copy_reg.py
import copy_reg # precompiled from /usr/local/lib/python2.2/copy_reg.pyc
# /usr/local/lib/python2.2/types.pyc matches /usr/local/lib/python2.2/typ=
es.py
import types # precompiled from /usr/local/lib/python2.2/types.pyc
# /usr/local/lib/python2.2/__future__.pyc matches /usr/local/lib/python2.=
2/__future__.py
import __future__ # precompiled from /usr/local/lib/python2.2/__future__.=
pyc
Python 2.2.1 (#1, Apr 18 2002, 01:54:11)=20
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
dlopen("/usr/local/lib/python2.2/lib-dynload/readline.so", 2);
import readline # dynamically loaded from /usr/local/lib/python2.2/lib-dy=
nload/readline.so
>>> import unittest
# /usr/local/lib/python2.2/site-packages/unittest.pyc matches /usr/local/=
lib/python2.2/site-packages/unittest.py
import unittest # precompiled from /usr/local/lib/python2.2/site-packages=
/unittest.pyc
dlopen("/usr/local/lib/python2.2/lib-dynload/time.so", 2);
import time # dynamically loaded from /usr/local/lib/python2.2/lib-dynloa=
d/time.so
# /usr/local/lib/python2.2/traceback.pyc matches /usr/local/lib/python2.2=
/traceback.py
import traceback # precompiled from /usr/local/lib/python2.2/traceback.py=
c
# /usr/local/lib/python2.2/linecache.pyc matches /usr/local/lib/python2.2=
/linecache.py
import linecache # precompiled from /usr/local/lib/python2.2/linecache.py=
c
# /usr/local/lib/python2.2/string.pyc matches /usr/local/lib/python2.2/st=
ring.py
import string # precompiled from /usr/local/lib/python2.2/string.pyc
dlopen("/usr/local/lib/python2.2/lib-dynload/strop.so", 2);
import strop # dynamically loaded from /usr/local/lib/python2.2/lib-dynlo=
ad/strop.so
>>> print unittest.__version__
1.1.1.1
>>>=20
---------------------------------------------------------------

I'm hoping that means they didn't bother to populate __version__ correctl=
y!  ;^)

-- Steve.

Stephen C. Waterbury  http://misspiggy.gsfc.nasa.gov/people/waterbug.html
    "An idiot with a computer is a faster, better idiot." - Rick Julius

Re: [Pypgsql-users] Unit test script appears to have problems

[Gerhard <ger...@gm...>]

* Steve Waterbury <ste...@gs...> [2002-05-20 16:41 -0400]:
> Gerhard Häring wrote:
> > 
> > * Steve Waterbury <ste...@gs...> [2002-05-20 09:37 -0400]:
> > > I installed PyPgSQL and ran PgSQLTestCases.py, which gave 29 errors -- but
> > > these seem to be problems with the test scripts rather than with
> > > PyPgSQL itself.  All errors came down to 4 methods missing in various unit
> > > test scripts:  "assertEqual", "assertEquals" [sic -- typo?],
> > > "failUnlessRaises", and "fail".
> > 
> > Strange. Which version of Python is this? If it is 2.1 or later, do you
> > use the included unittest module or did you perhaps overwrite it with an
> > updated or outdated version?
> 
> I'm using Python 2.2.1 (#1, Apr 18 2002, 01:54:11)

Ok. That's fine, reinstalling the original unittest.py and making sure
it is really used should already do the trick.

> and PyUnit 1.4.1, which I installed "over" the included one when I saw that 
> the tests were failing.

That isn't necessary. The pyunit in 2.2.1 seems to be _more_ up-to-date
than what can be found on the pyunit site. But every pyunit >= 1.4.0
should be ok from what I see.

> (They failed the same way with the PyUnit that was included in Python
> 2.2.1.) 

Really strange. Let's try to find out what happened:

You can start Python with "python -v" and then "import unittest". This
should show which unittest.py is really loaded. It should look about
like:

>>> import unittest
# /usr/local/lib/python2.2/unittest.pyc matches
# /usr/local/lib/python2.2/unittest.py
[...]

Then you can use "print unittest.__version__" to see the revision number
of the module.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Unit test script appears to have problems

[Steve W. <ste...@gs...>]

Gerhard H=E4ring wrote:
>=20
> * Steve Waterbury <ste...@gs...> [2002-05-20 09:37 -04=
00]:
> > I installed PyPgSQL and ran PgSQLTestCases.py, which gave 29 errors -=
- but
> > these seem to be problems with the test scripts rather than with
> > PyPgSQL itself.  All errors came down to 4 methods missing in various=
 unit
> > test scripts:  "assertEqual", "assertEquals" [sic -- typo?],
> > "failUnlessRaises", and "fail".
>=20
> Strange. Which version of Python is this? If it is 2.1 or later, do you
> use the included unittest module or did you perhaps overwrite it with a=
n
> updated or outdated version?

I'm using Python 2.2.1 (#1, Apr 18 2002, 01:54:11) and PyUnit=20
1.4.1, which I installed "over" the included one when I saw that=20
the tests were failing.  (They failed the same way with the PyUnit=20
that was included in Python 2.2.1.)=20

The version of PgSQLTestCases.py I have is (from the file):=20
PgSQLTestCases.py,v 1.16 2001/10/18 03:17:08 ballie01 Exp

> Btw. in the current pyPgSQL release some tests checking the length of
> cursor.description fail when you use PostgreSQL 7.2.x. This has been
> fixed in the CVS version.

That's good to know.  I'm using PostgreSQL 7.2.

I don't know whether this will help, but here is an edited version of=20
the session:

-----------------------------------------------------------------------

[waterbug@beeblebrox test]$ python PgSQLTestCases.py=20
.E.E.E...........E..E.E.E....E.E.E.E.E.E.E.E.....E.E.E.E.E.E.E.E.E..E.E..=
.E..E.E
Time: 1.011s

!!!FAILURES!!!
Test Results

Run: 51 Failures: 0 Errors: 29
There were 29 errors:
1) __main__.DBAPICompliance.CheckAPILevel
Traceback (most recent call last):
  File "PgSQLTestCases.py", line 81, in CheckAPILevel
    self.assertEqual(PgSQL.apilevel, '2.0',
AttributeError: DBAPICompliance instance has no attribute 'assertEqual'

... <snip> ...

5) __main__.PgSQLTestModuleInterface.CheckPgInt8
Traceback (most recent call last):
  File "PgSQLTestCases.py", line 196, in CheckPgInt8
    self.failUnlessRaises(OverflowError, pow, b, 2)
AttributeError: PgSQLTestModuleInterface instance has no attribute 'failU=
nlessRaises'

... <snip> ...

29) __main__.PgSQLTestCases.CheckSelectOfNonPrintableString
Traceback (most recent call last):
  File "PgSQLTestCases.py", line 693, in CheckSelectOfNonPrintableString
    self.fail(msg)
AttributeError: PgSQLTestCases instance has no attribute 'fail'

-----------------------------------------------------------------------

-- Steve.

Stephen C. Waterbury  http://misspiggy.gsfc.nasa.gov/people/waterbug.html

Re: [Pypgsql-users] Unit test script appears to have problems

[Gerhard <ger...@gm...>]

* Steve Waterbury <ste...@gs...> [2002-05-20 09:37 -0400]:
> I installed PyPgSQL and ran PgSQLTestCases.py, which gave 29 errors -- but 
> these seem to be problems with the test scripts rather than with 
> PyPgSQL itself.  All errors came down to 4 methods missing in various unit 
> test scripts:  "assertEqual", "assertEquals" [sic -- typo?], 
> "failUnlessRaises", and "fail".  

Strange. Which version of Python is this? If it is 2.1 or later, do you
use the included unittest module or did you perhaps overwrite it with an
updated or outdated version?

Btw. in the current pyPgSQL release some tests checking the length of
cursor.description fail when you use PostgreSQL 7.2.x. This has been
fixed in the CVS version.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: [Pypgsql-users] Unit test script appears to have problems

[Steve W. <ste...@gs...>]

Yep.  It's not complaining about not finding things in unittest; 
it's complaining about the scripts.  E.g.:

Run: 51 Failures: 0 Errors: 29
There were 29 errors:
1) __main__.DBAPICompliance.CheckAPILevel
Traceback (most recent call last):
  File "PgSQLTestCases.py", line 81, in CheckAPILevel
    self.assertEqual(PgSQL.apilevel, '2.0',
AttributeError: DBAPICompliance instance has no attribute 'assertEqual'

-- Steve.

Tom Jenkins wrote:
> 
> Have you installed PyUnit?
> http://pyunit.sourceforge.net
> 
> On Mon, 2002-05-20 at 09:37, Steve Waterbury wrote:
> > I installed PyPgSQL and ran PgSQLTestCases.py, which gave 29 errors -- but
> > these seem to be problems with the test scripts rather than with
> > PyPgSQL itself.  All errors came down to 4 methods missing in various unit
> > test scripts:  "assertEqual", "assertEquals" [sic -- typo?],
> > "failUnlessRaises", and "fail".
> >
> > -- Steve.
> 
> Tom Jenkins
> Development InfoStructure
> http://www.devis.com

Re: [Pypgsql-users] Unit test script appears to have problems

[Tom J. <tje...@de...>]

Have you installed PyUnit?
http://pyunit.sourceforge.net

On Mon, 2002-05-20 at 09:37, Steve Waterbury wrote:
> I installed PyPgSQL and ran PgSQLTestCases.py, which gave 29 errors -- but 
> these seem to be problems with the test scripts rather than with 
> PyPgSQL itself.  All errors came down to 4 methods missing in various unit 
> test scripts:  "assertEqual", "assertEquals" [sic -- typo?], 
> "failUnlessRaises", and "fail".  
> 
> -- Steve.
> 
> Stephen C. Waterbury  http://misspiggy.gsfc.nasa.gov/people/waterbug.html
>     "An idiot with a computer is a faster, better idiot." - Rick Julius
> 
> _______________________________________________________________
> Hundreds of nodes, one monster rendering program.
> Now that's a super model! Visit http://clustering.foundries.sf.net/
> 
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users
-- 

Tom Jenkins
Development InfoStructure
http://www.devis.com

[Pypgsql-users] Unit test script appears to have problems

[Steve W. <ste...@gs...>]

I installed PyPgSQL and ran PgSQLTestCases.py, which gave 29 errors -- but 
these seem to be problems with the test scripts rather than with 
PyPgSQL itself.  All errors came down to 4 methods missing in various unit 
test scripts:  "assertEqual", "assertEquals" [sic -- typo?], 
"failUnlessRaises", and "fail".  

-- Steve.

Stephen C. Waterbury  http://misspiggy.gsfc.nasa.gov/people/waterbug.html
    "An idiot with a computer is a faster, better idiot." - Rick Julius

[Pypgsql-users] Error: "Sorry, Too many clients already"

[Anthony D. <ad...@in...>]

Hi,

I am having some trouble when using the pypg interface to postgreSQL.

Every now and then (I haven't been able to isolate exactly when it 
happens) I encounter the error "Sorry, too many clients already." which 
I can only recover from by restarting postgres.

Postgres is using the default n=32 processes, which is much more than 
the number of connections I am aware of being made.  One of our 
applications using pypg runs as a cron job every 10 minutes, but all 
connections look as though they are being dropped at the end of each run 
(as expected).

Could this be a cursor issue? Could cursors remain on the server after 
my application finishes?  When should new cursors be used?  When should 
cursors be re-used for similar operations (e.g. a bunch of inserts).

Does pypg explicitly close all connections / cursors when it's instance 
is terminated?

Thanks, any insight would be greatly appreciated.

-Anthony

Re: [Pypgsql-users] getting list of tables & column information

[Billy G. A. <Bil...@mu...>]

"Steven D. Arnold" wrote:
> Hello,
> 
> I've recently converted several applications from pygresql to pypgsql, but 
> I have one piece of code that is giving me trouble.  This module uses 
> pygresql's db.get_tables() command to obtain a list of all tables in a 
> postgres database.  This is similar information to what you'd get by 
> starting up postgres at the command line and using the command '\dt'.
> 
> Does anyone know how to get a listing of all tables in a given database via 
> pypgsql, either via a specialized command or a SQL equivalent?
> 
> Thanks!

You can get psql to tell you what it uses to get the list of tables:

$ psql -E -c '\dt'
********* QUERY *********
SELECT c.relname as "Name", 'table'::text as "Type", u.usename as "Owner"
FROM pg_class c, pg_user u
WHERE c.relowner = u.usesysid AND c.relkind = 'r'
  AND c.relname !~ '^pg_'
UNION
SELECT c.relname as "Name", 'table'::text as "Type", NULL as "Owner"
FROM pg_class c
WHERE c.relkind = 'r'
  AND not exists (select 1 from pg_user where usesysid = c.relowner)
  AND c.relname !~ '^pg_'
ORDER BY "Name"
*************************

I hope this helps.
___________________________________________________________________________
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

[Pypgsql-users] getting list of tables & column information

[Steven D. A. <st...@ne...>]

Hello,

I've recently converted several applications from pygresql to pypgsql, but 
I have one piece of code that is giving me trouble.  This module uses 
pygresql's db.get_tables() command to obtain a list of all tables in a 
postgres database.  This is similar information to what you'd get by 
starting up postgres at the command line and using the command '\dt'.

Does anyone know how to get a listing of all tables in a given database via 
pypgsql, either via a specialized command or a SQL equivalent?

Thanks!

-------------------------------------------------------------- 
Steven D. Arnold                                    Neosynapse
st...@ne...                        Managing Partner
AIM: abraxan                       MSN: neo...@ho...