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

[Pypgsql-users] PyPgSQL build for Windows that'll handle PostgreSQL 8?

[Greg W. <gvw...@cs...>]

Hi.  Does anyone have a build of PyPgSQL for Windows XP and Python 2.3
that'll handle PostgreSQL 8?  In particular, does anyone have one with
mfuhr's fix for bug #1006782 that they could send me?  (Don't have a C/C++
build environment set up; know I should do it, but would like to put out
this fire first...)

Thanks,
Greg

Re: [Pypgsql-users] __unicodeConvert and sub-classing unicode

[Mike M. <zo...@je...>]

Hi Nicola.

Nicola Larosa wrote:

> I'm not claiming to be an expert, but I didn't see anything in the code that 
> needs the original unicode type, and nothing else. So yes, you should go 
> ahead, IMO.

Thanks for the tips.  I've reported it as bug.

Meanwhile I've managed to find a workaround that's at least slightly 
preferable than using a hacked pyPgSQL.py.  Luckily I had a wrapper 
around the callproc() method, so I've just added a few lines of code to 
convert all of my parameters to regular unicode strings before passing 
them on.

Mike.

Re: [Pypgsql-users] __unicodeConvert and sub-classing unicode

[Nicola L. <ni...@te...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Disclaimer: not an official response, just some bystander who happens to have 
delved deep into the code of pyPgSQL, while resisting the urge to fork 
it. ;-) ]


> I've experimented with hacking PgSQL.py to use isinstance() in the 
> various places instead.  ie. Instead of:
> 
>  if type(obj) is UnicodeType:
>   do_something()

This way of checking types is deprecated, exactly because of the problem you 
encountered.


> I've changed it to:
> 
>  if isinstance(obj, UnicodeType):
>   do_something()

This is how it's supposed to be done, at this moment.


> In my case at least, this appears to fix things, but I haven't tested it 
> intensively.
> 
> I realise that sub-classing 'str' and 'unicode' isn't a normal thing for 
> most people to do.

You are definitely supposed to be able to do that.


> Is that the only reason that the 'is' operator was used, or is it more
> complicated than that? 

Just historical reasons, probably.


> If someone who better understands the inner workings of pyPgSQL could 
> clarify it for me, I'd appreciate it.  Otherwise I'll go ahead and 
> report it as a bug.

I'm not claiming to be an expert, but I didn't see anything in the code that 
needs the original unicode type, and nothing else. So yes, you should go 
ahead, IMO.


- -- 
Nicola Larosa - ni...@te...

Unchecked police and military power undermine personal security,
and increase the risk of terrorism attacks. Unchecked terrorism only
increases the risk of terrorism attacks. Statistically, if both are
possible, I am more at risk from the first, and am likely to lose more.
 -- Daniel Staal, August 2004

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBfz/VXv0hgDImBm4RAhi5AKCAYlHCdAdirtQJRcjhGRlTYxtfFACgg5Ay
748fHMKPiUtq50djdy7gtbI=
=4piy
-----END PGP SIGNATURE-----

[Pypgsql-users] __unicodeConvert and sub-classing unicode

[Mike M. <zo...@je...>]

Hi everyone.

I'm thinking of reporting this as a bug properly, but it'd be good if 
someone with a better knowledge of pyPgSQL internals could confirm my 
line of reasoning first.


In my CGI script, I use my own subclass of the 'unicode' class rather 
than the regular unicode class.  My sub-class is very similar, apart 
from adding a few extra methods and member variables.  When I try to 
pass my customised unicode strings to a stored procedure call via the 
Cursor.callproc() method, however, pyPgSQL doesn't want to automatically 
encode them.  I can provide more detailed information about exactly what 
happens or attempt to produce a simplified test case if anyone wants it.

I've tracked this down to the Cursor.__unicodeConvert() method, which 
uses the 'is' operator to figure out if a particular object is a 
StringType or a UnicodeType.  Unfortunately this doesn't detect my 
sub-class of the unicode class, so it's simply not trying to encode it.

I've experimented with hacking PgSQL.py to use isinstance() in the 
various places instead.  ie. Instead of:

	if type(obj) is UnicodeType:
		do_something()

I've changed it to:

	if isinstance(obj, UnicodeType):
		do_something()

In my case at least, this appears to fix things, but I haven't tested it 
intensively.

I realise that sub-classing 'str' and 'unicode' isn't a normal thing for 
most people to do.  Is that the only reason that the 'is' operator was 
used, or is it more complicated than that?

If someone who better understands the inner workings of pyPgSQL could 
clarify it for me, I'd appreciate it.  Otherwise I'll go ahead and 
report it as a bug.

Thanks for any help.
Mike.

[Pypgsql-users] Problem with schema

[Joseph R. <ume...@gr...>]

It seems that the cursors are not respecting the search_path when I'm trying 
to use the new schema functionality in postgresql. I have made tables 
specifically in another schema (foo) and left public empty, only to find that 
when I connect with a new cursor (in $user,public) i can't create another 
table of the same name in public when I pass just a tablename.

I have been using pyPgSQL for a long time now, and I have a lot of code that 
depends on it.  I've been getting a lot of use out of the PgResultSet, and it 
will take a lot of work to change things around.

I can send you an example, but this is pretty simple to do in psql, and then 
test with the python cursor.
If I can be of any assistance please let me know.

Thanks
-- 
Joseph Rawson

[Pypgsql-users] Python Future Warning

[Terence M. <te...@i3...>]

=====================================================================
Sorry I replied to the last thread instead of starting a new one  
Duh!
=====================================================================
...

Thought I would do a heads up for the developers on this issue; just in
case no one has picked it up.

I get this logged...

/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py:2644: FutureWarning:
%u/%o/%x/%X of negative int will return a signed string in Python 2.4
and up


Cheers

[Pypgsql-users] Future warning

[Terence M. <te...@i3...>]

Thought I would do a heads up for the developers on this issue; just in case no one has picked it up.

I get this logged...

/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py:2644: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up


Cheers

Re: [Pypgsql-users] timestamp and mxDateTime

[Karsten H. <Kar...@gm...>]

> There is only one column in that table as it is a "test" for the 
> timestamp type since that is what is giving me trouble. Here is the SQL 
> that created it:
> 
> CREATE TABLE dailylog (
>    enttime        timestamp     -- time entered by the operator
> );
> 
> Which is why the error about "varchar(4)" is puzzling since I have none.
OK

- does it work manually via psql ?
- what happens if you do change the timestamp to varchar(4) ?
- which PG version is this on ?
- did you ever drop/add columns to that table after creation ?
- have you tried on a clean and empty database ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [Pypgsql-users] timestamp and mxDateTime

[Michael H. <Mi...@Hi...>]

Karsten Hilbert wrote:

>>--------------------------
>>from   pyPgSQL import PgSQL
>>from   mx.DateTime import *
>>
>>db = PgSQL.connect(dsn="localhost", database="test")
>>cursor = db.cursor()
>>
>>rightnow = now()
>>cursor.execute("insert into dailylog values (%s)", rightnow)
>>--------------------------
>>
>>That column in PostgreSQL was defined as a 'timestamp' type.
> 
> Erm, *which* column ? You certainly don't say in your insert
> query. Likely you are thinking it inserts into one column
> while it actually does insert into another.
> 
> 
>>libpq.OperationalError: ERROR:  value too long for type character varying(4)
> 
> Look out for varchar(4) columns in your table.

There is only one column in that table as it is a "test" for the 
timestamp type since that is what is giving me trouble. Here is the SQL 
that created it:

CREATE TABLE dailylog (
    enttime        timestamp     -- time entered by the operator
);

Which is why the error about "varchar(4)" is puzzling since I have none.

Thank you,
Michael

Re: [Pypgsql-users] timestamp and mxDateTime

[Karsten H. <Kar...@gm...>]

> --------------------------
> from   pyPgSQL import PgSQL
> from   mx.DateTime import *
> 
> db = PgSQL.connect(dsn="localhost", database="test")
> cursor = db.cursor()
> 
> rightnow = now()
> cursor.execute("insert into dailylog values (%s)", rightnow)
> --------------------------
> 
> That column in PostgreSQL was defined as a 'timestamp' type.
Erm, *which* column ? You certainly don't say in your insert
query. Likely you are thinking it inserts into one column
while it actually does insert into another.

> libpq.OperationalError: ERROR:  value too long for type character varying(4)
Look out for varchar(4) columns in your table.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

[Pypgsql-users] timestamp and mxDateTime

[Michael H. <Mi...@Hi...>]

Hello, first post.

I'm fairly new to Python, PostgreSQL and pyPgSQL so please forgive if 
I'm doing something dumb ...

How do you store an mxDateTime in a database? Here's the essence of my code:

--------------------------
from   pyPgSQL import PgSQL
from   mx.DateTime import *

db = PgSQL.connect(dsn="localhost", database="test")
cursor = db.cursor()

rightnow = now()
cursor.execute("insert into dailylog values (%s)", rightnow)
--------------------------

That column in PostgreSQL was defined as a 'timestamp' type.

This gives error:
libpq.OperationalError: ERROR:  value too long for type character varying(4)

Any help appreciated,
Michael

Re: [Pypgsql-users] How many cursors?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross M Karchner wrote:
| Apologies for the newbie question--
|
| Is there a limit on the number of cursor instances attatched to a
| particular connection? If not, is there any sort of recommended maximum?
|
There is no programmed limin in pyPgSQL, only the amount of memory you
have available.  I do not know if there is a limit in PostgreSQL for the
number of open cursors (or portals in pg speak).

- --
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBOh58nmIkMXoVVdURAjW2AKDUpPHMAs4qouVDN4lzYQJiDfo/FQCeP1q5
gfWI86VTR37+YfKEXgZkDfs=
=zqYn
-----END PGP SIGNATURE-----

[Pypgsql-users] How many cursors?

[Ross M K. <ro...@ka...>]

Apologies for the newbie question--

Is there a limit on the number of cursor instances attatched to a 
particular connection? If not, is there any sort of recommended maximum?

Re: [Pypgsql-users] pyPgSQL, threads and Solaris

[Jason I. <ja...@co...>]

> "/export/home/jason/awsrc/scooby/othersrc/fakeroot/lib/python2.3/site-packages/pyPgSQL/PgSQL.py",
> | line 3267, in fetchall
> |     self.res = self.conn.conn.query('FETCH ALL FROM "%s"' % self.name)
> | OperationalError: could not receive data from server: Error 0
> |
> | By using fetchone() I can usually get a few items but end up with a
> | similar traceback.
> |
> | pyPgSQL is built against Python 2.3.4 and PostgreSQL 7.3.4.  I'm not
> | really sure if its a problem in pyPgSQL, libpq or in Python threads
> | support on Solaris but thought I'd start hunting here first.
> |
> | The same code works fine in Linux, FreeBSD and OpenBSD.
> |
> | Any ideas?  I think my next course of action is to try and reproduce a
> | similar failure with C/libpq.
> |
> | Thanks,
> | Jason
> 
> My first guess is that you are using the same connection in multiple
> threads, which is dangerous as connections are not thread safe objects.
> This can cause the symptoms you are seeing.  Make sure that each thread
> has it's own connection object.

I'm opening the database connection in the main thread and getting a
cursor and doing the query in another thread while the first thread is
sleeping.. No other cursors or queries were opened - this is a very
simple test case.

I tried moving the connect() to the thread but it didn't help.  I
still have yet to do my C/libpq test tho.

Thanks,
Jason

Re: [Pypgsql-users] pyPgSQL, threads and Solaris

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Ish wrote:
| I'm running into problems using pyPgSQL DB-API interface on Solaris 9
| (with up to date patches) from a thread.  I get the following
| exception on a fetchall():
|
| Exception in thread Thread-1:
| Traceback (most recent call last):
|   File
|
"/export/home/jason/awsrc/scooby/othersrc/python/../fakeroot/lib/python2.3/threading.py",
| line 436, in __bootstrap
|     self.run()
|   File
|
"/export/home/jason/awsrc/scooby/othersrc/python/../fakeroot/lib/python2.3/threading.py",
| line 416, in run
|     self.__target(*self.__args, **self.__kwargs)
|   File "playpen/test_largequery.pl", line 40, in the_thread
|     res = c.fetchall()
|   File
|
"/export/home/jason/awsrc/scooby/othersrc/fakeroot/lib/python2.3/site-packages/pyPgSQL/PgSQL.py",
| line 3267, in fetchall
|     self.res = self.conn.conn.query('FETCH ALL FROM "%s"' % self.name)
| OperationalError: could not receive data from server: Error 0
|
| By using fetchone() I can usually get a few items but end up with a
| similar traceback.
|
| pyPgSQL is built against Python 2.3.4 and PostgreSQL 7.3.4.  I'm not
| really sure if its a problem in pyPgSQL, libpq or in Python threads
| support on Solaris but thought I'd start hunting here first.
|
| The same code works fine in Linux, FreeBSD and OpenBSD.
|
| Any ideas?  I think my next course of action is to try and reproduce a
| similar failure with C/libpq.
|
| Thanks,
| Jason

My first guess is that you are using the same connection in multiple
threads, which is dangerous as connections are not thread safe objects.
This can cause the symptoms you are seeing.  Make sure that each thread
has it's own connection object.
- --
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBNAISnmIkMXoVVdURAgMJAKCqql/cZ2/xDkruaLrmJlLD8c79FACfXu86
QhGI4WJB45d7BCtnuP3+TbA=
=UI+c
-----END PGP SIGNATURE-----

Re: [Pypgsql-users] date types incoherent per DP-API 2.0?

[Karsten H. <Kar...@gm...>]

> psycopg - the function yields values of <type 'datetime'> instead.
  ^^^^^^^
...
> I am perfectly willing to jump over to the devel list and do this
> coding myself; but I wanted to ask here first in case I'm
> misunderstanding something.
Yep. Seems like you are posting to the wrong list ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

[Pypgsql-users] pyPgSQL, threads and Solaris

[Jason I. <ja...@co...>]

I'm running into problems using pyPgSQL DB-API interface on Solaris 9
(with up to date patches) from a thread.  I get the following
exception on a fetchall():

Exception in thread Thread-1:
Traceback (most recent call last):
  File
"/export/home/jason/awsrc/scooby/othersrc/python/../fakeroot/lib/python2.3/threading.py",
line 436, in __bootstrap
    self.run()
  File
"/export/home/jason/awsrc/scooby/othersrc/python/../fakeroot/lib/python2.3/threading.py",
line 416, in run
    self.__target(*self.__args, **self.__kwargs)
  File "playpen/test_largequery.pl", line 40, in the_thread
    res = c.fetchall()
  File
"/export/home/jason/awsrc/scooby/othersrc/fakeroot/lib/python2.3/site-packages/pyPgSQL/PgSQL.py",
line 3267, in fetchall
    self.res = self.conn.conn.query('FETCH ALL FROM "%s"' % self.name)
OperationalError: could not receive data from server: Error 0

By using fetchone() I can usually get a few items but end up with a
similar traceback.

pyPgSQL is built against Python 2.3.4 and PostgreSQL 7.3.4.  I'm not
really sure if its a problem in pyPgSQL, libpq or in Python threads
support on Solaris but thought I'd start hunting here first.

The same code works fine in Linux, FreeBSD and OpenBSD.

Any ideas?  I think my next course of action is to try and reproduce a
similar failure with C/libpq.

Thanks,
Jason

[Pypgsql-users] date types incoherent per DP-API 2.0?

[Brandon C. R. <bra...@oi...>]

The Python DB-API 2.0 describes the following function and type:

        Date(year,month,day)
            This function constructs an object holding a date value.

        DATETIME
            This type object is used to describe date/time columns in
            a database.

If one naively assumes that the Date(...) function will return
instances of the type DATETIME, then one will be disappointed by
psycopg - the function yields values of <type 'datetime'> instead.

More surprising is that psycopg actually seems to violate the standard
by not using not using the type DATETIME when returning timestamps
from database tables; selecting a value of SQL type TIMESTAMP from a
table returns a full-fledged DateTime object:

>>> d
<DateTime object for '2003-12-17 00:00:00.00' at 401dce58>
>>> type(d)
<type 'DateTime'>

where 'DateTime' comes from the mx.DateTime module.  In order to make
psycopg consistent, I suggest:

   - That psycopg.DATETIME, rather than being an apparently unused
     type, become a reference to the mx.DateTime.DateTime type that
     psycopg is actually using to return dates.  I believe that this
     change is necessary to bring this aspect of psycopg into
     conformance with the DB-API.

   - That the psycopg.Date(...) and other time construction functions
     return DateTime instances so they can be most easily compared
     with dates and times returned by queries.

I am perfectly willing to jump over to the devel list and do this
coding myself; but I wanted to ask here first in case I'm
misunderstanding something.

Thanks,
-- 
Brandon Craig Rhodes                         http://www.rhodesmill.org/brandon
Georgia Tech                                            br...@oi...

Re: [Pypgsql-users] (no subject)

[Bob K. <rjk...@al...>]

On Monday 16 August 2004 10:28 am, Blyth A J C (Comp) wrote:
> I am trying execute the following and keep getting an error.
>
> self._query       =     "\d syslogdb"
> com.execute(self.query)
>
> What I can to do is to write a little program in python that will get a
> description (type definition) for a table.  -  HELP
>
>
> Andrew

One approach to consider is to run psql with the -E flag. Then when you run 
commands like "\d syslogdb", psql will show you the SQL it runs itself in 
order to retrieve the information. I think the reason your query fails is 
because a number of commands are run to get the result.

.... Bob

Re: [Pypgsql-users] (no subject)

[<fra...@cl...>]

Blyth A J C (Comp) wrote:

> I am trying execute the following and keep getting an error.
>
> self._query =3D =93\d syslogdb=94
>
> com.execute(self.query)
>
> What I can to do is to write a little program in python that will get=20
> a description (type definition) for a table. - HELP
>
> Andrew
>
try :

SELECT * from pg_tables

and dig in table named with pg_ prefix

[Pypgsql-users] (no subject)

[Blyth A J C \(Comp\) <ajc...@gl...>]

I am trying execute the following and keep getting an error.
=20
self._query       =3D     "\d syslogdb"
com.execute(self.query)
=20
What I can to do is to write a little program in python that will get a
description (type definition) for a table.  -  HELP
=20
=20
Andrew

Re: [Pypgsql-users] connect questions

[gianluca <ma...@em...>]

Alle 09:17, gioved=EC 12 agosto 2004, Tim Smith, ha scritto:

> PgSQL.connect(host=3D"10.0.0.1",database=3D"training",user=3D"pgsql",pass=
word=3D"")

from pyPgSQL import PgSQL

host=3D"your_host"
port=3D"5432"
database=3D"your_db"
user=3D"user_name"
password=3D"your_password"

strCnn=3D host + ":" + port + ":" + database + ":" + user + ":" + password

cnn =3D PgSQL.connect(strCnn)

=2D-=20
Saluti=20
gs

If you think things can't get worse it's probably only because you
lack sufficient imagination.

[Pypgsql-users] connect questions

[Tim S. <ti...@cq...>]

hello people, i know this is probably a really dumb question, but i 
can't seem to connect to my postgresql db. here is my code

from pyPgSQL import PgSQL

def Connect():
    db = 
PgSQL.connect(host="10.0.0.1",database="training",user="pgsql",password="")

and here is the error thats out putted

"user "timothy" does not exist"

timothy is the user thats logged into the system. so what am i doing 
wrong which makes it ignore the user i'm attempting to connect as?

[Pypgsql-users] Panther error

[Jay M. <jm...@ua...>]

Greetings;

I am trying to install pyPgSQL on an ibook running (as of last night  
which might have something to do with it or not) system version 10.3.5,  
kernel version 7.5.0,  PostgreSQL 7.4.3 and MacPython 2.3. I did  
install the Python add-ons. When Running
python setup.py build I get:

/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
distutils/dist.py:213: UserWarning: 'licence' distribution option is  
deprecated; use 'license'
   warnings.warn(msg)
running install
running build
running build_py
running build_ext
building 'pyPgSQL.libpq.libpqmodule' extension
gcc -Wl,-F. -Wl,-F. -bundle -framework Python  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/libpqmodule.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgboolean.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgint2object.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgint8object.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgversion.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pglargeobject.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgnotify.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgconnection.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pgresult.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/pymemstrdup.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/port/strtoll.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/port/strtoull.o  
build/temp.darwin-7.5.0-Power_Macintosh-2.3/port/strtok.o  
-L/usr/local/pgsql/lib -lpq -lssl -lcrypto -o  
build/lib.darwin-7.5.0-Power_Macintosh-2.3/pyPgSQL/libpq/libpqmodule.so
ld: Undefined symbols:
_error_message
_krb5_cc_close
_krb5_cc_default
_krb5_cc_get_principal
_krb5_free_context
_krb5_free_error
_krb5_free_principal
_krb5_init_context
_krb5_sendauth
_krb5_sname_to_principal
_krb5_unparse_name
error: command 'gcc' failed with exit status 1

Any help would be appreciated.

Thanks

Jay mutter

[Pypgsql-users] Test errors

[Tom D. <ts...@ts...>]

Aloha all,

After installing pypgsql on my Mac OS X 10.3 with PostgreSQL 7.4, I get
the following errors on the test suite (see below).  The archive shows
that this problem has been reported twice before, and apparently fixed,
but I couldn't find the fix.  Please note that this is the initial
installation of pypgsql on my machine.

Thanks in advance for your help.

Tom

........................................F.F.......................
======================================================================
FAIL: CheckDoMoreResultObjectChecks (__main__.PgSQLTestCases)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/PgSQLTestCases.py", line 817, in
CheckDoMoreResultObjectChecks
    self.fail(msg)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/unittest.py",
line 260, in fail
    raise self.failureException, msg
AssertionError: '7.4'

======================================================================
FAIL: Test execute() with a singleton string as the parameter.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/PgSQLTestCases.py", line 639, in CheckExecuteWithSingleton
    "Length of cur.description is %d, it should be %d." %
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/unittest.py",
line 292, in failUnlessEqual
    raise self.failureException, \
AssertionError: Length of cur.description is 11, it should be 4.

----------------------------------------------------------------------
Ran 66 tests in 2.322s

FAILED (failures=2)


Thomas S. Dye, Ph.D.
T. S. Dye & Colleagues, Archaeologists, Inc.
735 Bishop Street, Suite 315
Honolulu, Hawai`i 96813
Voice (808) 387-9352
Fax (808) 529-0884
http://www.tsdye.com