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

Re: [Pypgsql-users] Support for Python 2.3 beta under windows...

[Gerhard <gh...@gh...>]

* Benjamin Scherrey <sch...@pr...> [2003-03-29 22:07 -0500]:
> Is there (or will there soon be) a build available for Python 2.3 win32?

As soon as somebody builds one. You could, too. Only free tools are
required to do so. There's even a README.win32 in the pyPgSQL source
distribution.

> I'd really like to use pypgsql for my app but, unfortunately, I
> required the "https" connectivity that isn't available in the 2.2
> release.

I've once made a replacement SSL-enabled _socket.pyd that's currently
available at:

http://pypgsql.sourceforge.net/misc/python-ssl.html

I'll most likely move it to my new homepage soon (see sig).

> When I tried to install the binary for Python 2.2, it just complained
> that it couldn't detect my 2.2 install (rightfully so) but wouldn't
> let me force it to goto my 2.3 install. 

You could try copying the files from the 2.2 directories to the 2.3
directories. But it will likely fail, as C-API compatibilty is only
guaranteed between the same major.minor Python releases (with the
major.minor.micro scheme).

Gerhard
-- 
mail:   gh...@gh...
web:    http://ghaering.de/

[Pypgsql-users] Support for Python 2.3 beta under windows...

[Benjamin S. <sch...@pr...>]

Is there (or will there soon be) a build available for Python 2.3 win32? I'd really like to use pypgsql 
for my app but, unfortunately, I required the "https" connectivity that isn't available in the 2.2 
release. When I tried to install the binary for Python 2.2, it just complained that it couldn't detect my 
2.2 install (rightfully so) but wouldn't let me force it to goto my 2.3 install. 

	many thanx,

		Ben Scherrey

Re: [Pypgsql-users] ImportError with libpq.so.2

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

"Billy G. Allie" wrote:
> "Todd Reed" wrote:
> > I ended up installing pyPgSQL 2.3 from the source distribution, and this
> > did resolve the ImportError.  However, there is an incompatibility between
> > pyPgSQL 2.3 and PostgreSQL 7.3.2 (and possibly other 7.3.x releases).  The
> > system table pg_type used to have a column called "typprtlen" which is no
> > longer present in PostgreSQL 7.3.2.  pyPgSQL makes a query on pg_type that
> > attempts to access this non-existent column to obtain information for the
> > "description" field of cursor objects.  I ended up modifying the query to
> > always return -1; I think "typprtlen" was used to find the display width
> > for the column.
> > 
> 
> The 2.3 release does have the typprtlen problem.  The CVS source contains a 
> fix for that problem as well as several others.

The 2.3 release does contain the fix for the typprtlen problem.  The change in 
the current CVS was to have display length in the cursor.description object 
return None instead of -1.

>                                                  I would recommend getting
> the latest source from CVS for the latest bug fixes.

I still recomend getting the latest source from CVS, though. :-)

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

Re: [Pypgsql-users] ImportError with libpq.so.2

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

"Todd Reed" wrote:
> I ended up installing pyPgSQL 2.3 from the source distribution, and this did
> resolve the ImportError.  However, there is an incompatibility between
> pyPgSQL 2.3 and PostgreSQL 7.3.2 (and possibly other 7.3.x releases).  The
> system table pg_type used to have a column called "typprtlen" which is no
> longer present in PostgreSQL 7.3.2.  pyPgSQL makes a query on pg_type that
> attempts to access this non-existent column to obtain information for the
> "description" field of cursor objects.  I ended up modifying the query to
> always return -1; I think "typprtlen" was used to find the display width for
> the column.
> 

The 2.3 release does have the typprtlen problem.  The CVS source contains a 
fix for that problem as well as several others.  I would recommend getting the 
latest source from CVS for the latest bug fixes.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

Re: [Pypgsql-users] ImportError with libpq.so.2

[<gh...@gh...>]

Todd Reed wrote:
> I ended up installing pyPgSQL 2.3 from the source distribution, and this did
> resolve the ImportError.  However, there is an incompatibility between
> pyPgSQL 2.3 and PostgreSQL 7.3.2 (and possibly other 7.3.x releases).  The
> system table pg_type used to have a column called "typprtlen" which is no
> longer present in PostgreSQL 7.3.2. [...]

This change was actually made in revision 1.18 of pyPgSQL/PgSQL.py

(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pypgsql/pypgsql/pyPgSQL/PgSQL.py)

and is in the 2.3 release. You seem to have old sources lying around.

-- Gerhard

Re: [Pypgsql-users] ImportError with libpq.so.2

[Todd R. <tr...@ko...>]

I ended up installing pyPgSQL 2.3 from the source distribution, and this did
resolve the ImportError.  However, there is an incompatibility between
pyPgSQL 2.3 and PostgreSQL 7.3.2 (and possibly other 7.3.x releases).  The
system table pg_type used to have a column called "typprtlen" which is no
longer present in PostgreSQL 7.3.2.  pyPgSQL makes a query on pg_type that
attempts to access this non-existent column to obtain information for the
"description" field of cursor objects.  I ended up modifying the query to
always return -1; I think "typprtlen" was used to find the display width for
the column.

----- Original Message -----
From: "Billy G. Allie" <Bil...@mu...>
To: "Todd Reed" <tr...@ko...>
Cc: <pyp...@li...>
Sent: Monday, March 03, 2003 10:15 PM
Subject: Re: [Pypgsql-users] ImportError with libpq.so.2


> "Todd Reed" wrote:
> > I had PostgreSQL 7.21 and pyPgSQL 2.2 installed and working on a RedHat
7.3
> > installation.  After upgrading to PostgreSQL 7.3.2, my scripts generated
an
> > ImportError as shown below:
> >
> > I found a copy libqp.so.2 in /usr/lib/pgsql/backup, and copied it to
> > /usr/lib.  After that, I received the following error:
> >
> > Any suggestions on fixing this problem?
>
> Todd,
>
> 1.  remove the libpq.so.2 from /usr/lib.
> 2.  get the latest source code from CVS or get the source distribution
from SF.
> 3.  build pyPgSQL 2.3 from source.
>
> The backup copy of libpq.so.2 was from the previous version of PostgreSQL
> and will not work.  The RPM was not built with the version of libpq.so you
> have for the newer version of PostgreSQL.  Building from the source should
> resolve the issutes your are expirencing.

Re: [Pypgsql-users] ImportError with libpq.so.2

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

"Todd Reed" wrote:
> I had PostgreSQL 7.21 and pyPgSQL 2.2 installed and working on a RedHat 7.3
> installation.  After upgrading to PostgreSQL 7.3.2, my scripts generated an
> ImportError as shown below:
> 
> I found a copy libqp.so.2 in /usr/lib/pgsql/backup, and copied it to
> /usr/lib.  After that, I received the following error:
> 
> Any suggestions on fixing this problem?

Todd,

1.  remove the libpq.so.2 from /usr/lib.
2.  get the latest source code from CVS or get the source distribution from SF.
3.  build pyPgSQL 2.3 from source.

The backup copy of libpq.so.2 was from the previous version of PostgreSQL
and will not work.  The RPM was not built with the version of libpq.so you
have for the newer version of PostgreSQL.  Building from the source should
resolve the issutes your are expirencing.

[Pypgsql-users] ImportError with libpq.so.2

[Todd R. <tr...@ko...>]

I had PostgreSQL 7.21 and pyPgSQL 2.2 installed and working on a RedHat 7.3
installation.  After upgrading to PostgreSQL 7.3.2, my scripts generated an
ImportError as shown below:

Traceback (most recent call last):
  File
"/home/autoprocess/Developer/Source/Applications/Sales/FetchEmail.py", line
3, in ?
    from pyPgSQL import PgSQL as DBModule
  File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 356, in ?
    from libpq import *
  File "/usr/lib/python2.2/site-packages/pyPgSQL/libpq/__init__.py", line
23, in ?
    from libpq import *
ImportError: libpq.so.2: cannot open shared object file: No such file or
directory

I upgraded to pyPgSQL 2.3 by installing the RPM from SourceForge, but the
above error persisted.

I found a copy libqp.so.2 in /usr/lib/pgsql/backup, and copied it to
/usr/lib.  After that, I received the following error:

Traceback (most recent call last):
  File
"/home/autoprocess/Developer/Source/Applications/Sales/FetchEmail.py", line
3, in ?
    from pyPgSQL import PgSQL as DBModule
  File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 349, in ?
    from libpq import *
  File "/usr/lib/python2.2/site-packages/pyPgSQL/libpq/__init__.py", line
23, in ?
    from libpq import *
ImportError: /usr/lib/python2.2/site-packages/pyPgSQL/libpq/libpqmodule.so:
undefined symbol: PyUnicodeUCS4_EncodeDecimal

Any suggestions on fixing this problem?

--
Todd Reed
tr...@ko...
Kojents Inc.

[Pypgsql-users] notifies

[Gordon K. <gk...@us...>]

There may be a bug in "notifies()" or I may be wrong - why
do I have to be sending events inorder to receive notifies?
-----
db.conn.query("listen event_1")

def do():
        x = db.conn.notifies()
	if x != None: print x

import time
start = time.time()
counter = 1
while 1:
        passed = time.time() - start
        if passed > counter:
                print counter
                counter = counter + 1
                if passed > 10: break

                # --- the unusual send
                #db.conn.query("listen event_1")
                db.conn.query("notify ignorable")
        do()

-----
pyPgSQL  2.3.1-10
(Debian Package: python2.2-pgsql_2.0-3.1_i386.deb)
PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4
libc6 2.2.5-14.3

Re: [Pypgsql-users] Re: Problem using dynamic table names with pyformat

[Ganesan R <rga...@my...>]

>>>>> "Gerhard" =3D=3D Gerhard H=E4ring <ger...@op...> w=
rites:

> Well, first, SELECT * sucks ;-)

Agreed :-)

> A combination of Python expansion and DB-API quoting should do.

> cursor.execute("SEELCT a, b, c FROM %s WHERE ID=3D%%s" % table, (25,))

> Note the doubled percent sign to make the Python expansion leave the se=
cond
> %s (for the DB-API quoting) alone.

Ahh, that will do the trick, thank you :-).=20

>>> The % operator expects a tuple, so this should work:
>>>=20
>>> cursor.execute("SELECT * FROM %s WHERE id =3D %s" % (table, 25))
>>>=20
>>> but I haven't tried it of course.
>>=20
>> That works. But that will disable cursor optimization. [...]

> In theory, that's true. In reality, PostgreSQL started supporst
> PREPARE/EXECUTE only in 7.3, and we don't automatically use that.

> But you can *explicitely* use PREPARE/EXECUTE with pyPgSQL just fine.

That's good to know. Thanks again.

--=20
Ganesan R=20

[Pypgsql-users] Re: Problem using dynamic table names with pyformat

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

Ganesan R <rganesan-l=YSG...@pu...> wrote:
> On Thu, Feb 13, 2003 at 11:02:36PM -0800, Bob Terek wrote:
>> 
>> > I then tried
>> >
>> > cursor.execute("SELECT * FROM %s WHERE id = %s" % table, 25)
>> >
>> > This doesn't work either because the % operator complains about "not enough
>> > arguments for format string". I finally worked around by using
>> >
>> > Is there a syntactically clear alternative?

Well, first, SELECT * sucks ;-)

A combination of Python expansion and DB-API quoting should do.

cursor.execute("SEELCT a, b, c FROM %s WHERE ID=%%s" % table, (25,))

Note the doubled percent sign to make the Python expansion leave the second
%s (for the DB-API quoting) alone.

>> The % operator expects a tuple, so this should work:
>> 
>> cursor.execute("SELECT * FROM %s WHERE id = %s" % (table, 25))
>> 
>> but I haven't tried it of course.
> 
> That works. But that will disable cursor optimization. [...]

In theory, that's true. In reality, PostgreSQL started supporst
PREPARE/EXECUTE only in 7.3, and we don't automatically use that.

But you can *explicitely* use PREPARE/EXECUTE with pyPgSQL just fine.

-- Gerhard

Re: [Pypgsql-users] Problem using dynamic table names with pyformat

[Ganesan R <rga...@my...>]

On Thu, Feb 13, 2003 at 11:02:36PM -0800, Bob Terek wrote:
> 
> > I then tried
> >
> > cursor.execute("SELECT * FROM %s WHERE id = %s" % table, 25)
> >
> > This doesn't work either because the % operator complains about "not enough
> > arguments for format string". I finally worked around by using
> >
> > Is there a syntactically clear alternative?
> 
> The % operator expects a tuple, so this should work:
> 
> cursor.execute("SELECT * FROM %s WHERE id = %s" % (table, 25))
> 
> but I haven't tried it of course.

That works. But that will disable cursor optimization. From the DB-API-2.0
specification for cursor.execute():

A reference to the operation will be retained by the
cursor.  If the same operation object is passed in again,
then the cursor can optimize its behavior.  This is most
effective for algorithms where the same operation is used,
but different parameters are bound to it (many times).

Ganesan

-- 
Ganesan R

[Pypgsql-users] Problem using dynamic table names with pyformat

[Ganesan R <rga...@my...>]

Hi,

I have an application where the table name is known only at run time. Imagine
something like

cursor.execute("SELECT * FROM %s WHERE id = %s", table, 25)

This doesn't work. pyPgSQL appears to quote all arguments passed via
pyformat which causes a syntax error. I am not sure where this is bug
because the table name is not a SQL parameter.

I then tried

cursor.execute("SELECT * FROM %s WHERE id = %s" % table, 25)

This doesn't work either because the % operator complains about "not enough
arguments for format string". I finally worked around by using 

cursor.execute("SELECT * FROM " + table + " WHERE id = %s", 25)

Is there a syntactically clear alternative?

Ganesan

Re: [Pypgsql-users] Memory leak?

[Sean R. <ja...@tu...>]

On Sun, Feb 02, 2003 at 11:49:48PM -0500, Billy G. Allie wrote:
>I created the table above and ran the given python code for 60 CPU minutes.
>I did not experience any memory growth.  My memory started out at 5.3MB and 
>stayed there.  Note: the table was empty for this test.

Yeah, the table on my end is empty as well.  I mean, I'm able to
reproduce it with an empty table...

>Does the sample code cause memory growth on all your machines?

I've only run it on two machines.  Let me try another machine real
quick...  I've just tried it on another 7.3 machine and and 8.0 machine,
all similar specs to what I mentioned before, but not machines I had
tested before.  They are both exhibiting memory leaks.  Over 1.5 CPU
minutes I see about 15MB of growth (20MB total), with empty tables.

>I will inspect the code to see if anything obvious stands out.  Given the 
>simplicity of the sample code, it would seem that the leak may be related to 
>the libpq result object.

That's kind of what I'm thinking as well.

Sean
-- 
 Hi, my name's Sean, but my friends call me...  Actually, my friends USUALLY
 e-mail me...  -- Sean Reifschneider, 2000
Sean Reifschneider, Inimitably Superfluous <ja...@tu...>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin

Re: [Pypgsql-users] Memory leak?

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

Sean Reifschneider wrote:
> Greetings.  I've been switching some of my code over to PyPgSQL and it
> looks like I'm running into a memory leak in PyPgSQL.  I have two
> different applications running on 6 different machines, all of them but
> one exhibit growth in memory utilization.
> 
> I wish I had a solution, but at the moment I only have some data points:
> 
>    The two applications are not very similar.
> 
>    All systems are running Postgres 7.3 and 7.3.1 and PyPgSQL 2.3.  All
>    systems are running Python 2.2.2, the 8.0 machines via Red Hat RPMs,
>    the 7.3 machines via the python.org RPMs.
> 
>    4 systems are running Red Hat 7.3, 2 are running Red Hat 8.0.  The
>    one machine that doesn't seem to be exhibiting the problem is an 8.0
>    machine.  The 8.0 machines are both running the Red Hat "7.3-6" beta
>    RPMs for postgresql.  The others are running 7.3.1 beta RPMs.
> 
>    I have converted one of the applications to use psycopg and PoPy
>    (Ugh), and neither of these exhibit any real memory "leaking" on the
>    the 8.0 machine that leaks with PyPgSQL.
> 
>    I haven't been able to use PyPgSQL 2.2 with PostgreSQL 7.3.

pyPgSQL 2.2 won't run with PostgreSQL 7.3.  You need at least pyPgSQL 2.3 to 
work with PostgreSQL 7.3

> Code that exhibits the problem:
> 
>    from pyPgSQL import PgSQL as db
>    import random
> 
>    co = db.connect('::pypgsqltest')
>    cu = co.cursor()
> 
>    while 1:
>       s = str(random.randrange(0, 1000000))
>       cu.execute('SELECT id FROM a WHERE i = %s AND s = %s;', 3, s)
> 
> With a schema of:
> 
>    CREATE TABLE a (
>       id serial,
>       i integer,
>       s text UNIQUE
>       );
> 
> This code has been running for 3 CPU minutes and increased in RAM
> utilization from 5.5MB to 12.6MB and continues to grow...
>     [...]

I created the table above and ran the given python code for 60 CPU minutes.
I did not experience any memory growth.  My memory started out at 5.3MB and 
stayed there.  Note: the table was empty for this test.

I then populated the table with ~1000 records and re-ran the test with the 
same result: no memory growth.

Can you tell my how many rows your sample table contains?

Does the sample code cause memory growth on all your machines?

I will inspect the code to see if anything obvious stands out.  Given the 
simplicity of the sample code, it would seem that the leak may be related to 
the libpq result object.

>     [...]
> I wish I had an idea of where exactly the leek is happening, but I hope
> this helps at least some...
> 
> Thanks,
> Sean

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

[Pypgsql-users] Memory leak?

[Sean R. <jaf...@tu...>]

Greetings.  I've been switching some of my code over to PyPgSQL and it
looks like I'm running into a memory leak in PyPgSQL.  I have two
different applications running on 6 different machines, all of them but
one exhibit growth in memory utilization.

I wish I had a solution, but at the moment I only have some data points:

   The two applications are not very similar.

   All systems are running Postgres 7.3 and 7.3.1 and PyPgSQL 2.3.  All
   systems are running Python 2.2.2, the 8.0 machines via Red Hat RPMs,
   the 7.3 machines via the python.org RPMs.

   4 systems are running Red Hat 7.3, 2 are running Red Hat 8.0.  The
   one machine that doesn't seem to be exhibiting the problem is an 8.0
   machine.  The 8.0 machines are both running the Red Hat "7.3-6" beta
   RPMs for postgresql.  The others are running 7.3.1 beta RPMs.

   I have converted one of the applications to use psycopg and PoPy
   (Ugh), and neither of these exhibit any real memory "leaking" on the
   the 8.0 machine that leaks with PyPgSQL.

   I haven't been able to use PyPgSQL 2.2 with PostgreSQL 7.3.

Code that exhibits the problem:

   from pyPgSQL import PgSQL as db
   import random

   co = db.connect('::pypgsqltest')
   cu = co.cursor()

   while 1:
      s = str(random.randrange(0, 1000000))
      cu.execute('SELECT id FROM a WHERE i = %s AND s = %s;', 3, s)

With a schema of:

   CREATE TABLE a (
      id serial,
      i integer,
      s text UNIQUE
      );

This code has been running for 3 CPU minutes and increased in RAM
utilization from 5.5MB to 12.6MB and continues to grow...

   [root@toomuchcoffee tmp]# ps -awlx | grep test3
   000     0 20463 17568  25   0 13208 10768 -     R    pts/1      3:03 python ./test3
   [root@toomuchcoffee tmp]# ps -awlx | grep test3
   000     0 20463 17568  25   0 14732 12300 -     R    pts/1      4:00 python ./test3
                                 ^^^^^ ^^^^^
                                 Total  RSS

Long-running jobs just tend to start swapping a lot after running for 8
to 12 hours full-speed, or weeks at slower rates.

For example, a minimal conversion of this program to use pyscopg
produces:

   000     0 20761 17457  16   0  5184 2740 schedu S    pts/0      0:02 python ./test3.psycopg
   000     0 20804 17457  15   0  5184 2740 schedu S    pts/0      1:06 python ./test3.psycopg

I wish I had an idea of where exactly the leek is happening, but I hope
this helps at least some...

Thanks,
Sean
-- 
 The question of whether a computer can think is no more interesting than the
 question of whether a submarine can swim."  -- Edsgar W. Dijkstra (1930-2002)
Sean Reifschneider, Inimitably Superfluous <ja...@tu...>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin

[Pypgsql-users] Re: Running installation tests

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

Mario Ruggier <mario=xpR...@pu...> wrote:
> [...] ps: I noticed that doing 'reply' to messages on this list will only
> reply to the individual sender and not to the list. This is on purpose?

It's on purpose. The alternative is reply-to rewriting by the mailing list
software (which in the case of Mailman used here can be activated).

Whole wars have been fought on this issue and it's possible to argument for
both ways, as seen here:

http://www.unicom.com/pw/reply-to-harmful.html

and here:

http://www.metasystema.org/essays/reply-to-useful.mhtml

<ot>
Of course real [tm] mail user agents (like mutt ;-) have different
intuitive reply factilities like reply (bound to 'r'), group-reply (bound
to 'g') and list-reply (bound to 'L'). So reply-to rewriting makes the most
sense for users of lesser MUAs :-)
</ot>

Or you can just use the NNTP interface at news.gmane.org (explained at
http://news.gmane.org/) like I do right now. The newsgroup name is
gmane.comp.python.db.pypgsql.over there. (Caveat: you still need to be
subscribed to post, but you can disable email delivery in your Mailman
preferences if you want to switch to NNTP completely).

ciao,

Gerhard
-- 
Gerhard Häring
OPUS GmbH München
Tel.: +49 89 - 889 49 7 - 32
http://www.opus-gmbh.net/

Re: [Pypgsql-users] Re: Running installation tests

[Mario R. <ma...@ru...>]

Thanks. So my conclusion (in my just-sent 2nd email) is correct.
Following up, wouldn't it be even simpler to introduce another file,
called test/PySQLTestCasesConfig.py, that simply contains something
a dict with parameters for user, password and whatever else may be =20
necessary.
The test py imports this dict, and uses the specified values whenever =20=

necessary.
(This makes it easier to rerun the tests under different conditions, or =20=

even to supply
these pieces of data dynamically).

Cheers, mario

ps: I noticed that doing 'reply' to messages on this list will only =20
reply to the
individual sender and not to the list. This is on purpose?


On mercredi, jan 22, 2003, at 09:52 Europe/Amsterdam, Gerhard H=E4ring =20=

wrote:

> Mario Ruggier <mario=3Dx...@pu...> wrote:
>> Hello,
>>
>> am installing pyPgSQL 2.3, and seems to be all OK. When I try to run
>> the tests (as a user
>> for whom there is a postgres user with the same name), i get the
>> following error:
>>
>> =
=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
>> ERROR: CheckCloseConnection (__main__.PgSQLTestCases)
>> =
----------------------------------------------------------------------
>> Traceback (most recent call last):
>>    File "test/PgSQLTestCases.py", line 401, in setUp
>>      self.cnx =3D PgSQL.connect(database=3D'template1')
>>    File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line =20
>> 2118,
>> in connect
>>      return Connection(connInfo, client_encoding, unicode_results)
>>    File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line =20
>> 2215,
>> in __init__
>>      raise DatabaseError, m
>> DatabaseError: fe_sendauth: no password supplied
>>
>> and similar error foll all subsequent tests.
>>
>> How do i supply him the password?
>
> Short answer: in the connect function of the pyPgSQL.PgSQL module. =20
> It's all
> documented there.
>
> Longer answer: This is a corner of pyPgSQL that needs some work. I =20
> think we
> should make the database connection for the test cases configurable.
> Perhaps by use of a configuration file, perhaps by use of an =20
> environment
> variable. Any thoughts on this, Billy?
>
> The end of this message is a patch that makes it possible to use an
> environment variable called 'DSN' for this, so you can do something =20=

> like
>
> export DSN=3D"myhost::myuser:mypassword"
>
> or whatever is the way to do it in the shell you're using.
>
> HTH,
>
> Gerhard
>
> Patch follows:
>
> diff -r -C 3 ../pypgsql.orig/test/PgSQLTestCases.py =20
> ./test/PgSQLTestCases.py
> *** ../pypgsql.orig/test/PgSQLTestCases.py	Wed Jan 22 09:35:08 2003
> --- ./test/PgSQLTestCases.py	Wed Jan 22 09:39:48 2003
> ***************
> *** 82,88 ****
>   #		ify the test(s) accordingly.				=
|
>   # 01OCT2000 bga Initial release by Billy G. Allie.			=
|
>   =20
> =
#----------------------------------------------------------------------=20=

> -+
> ! import sys
>   import unittest
>   import types
>   import string
> --- 82,88 ----
>   #		ify the test(s) accordingly.				=
|
>   # 01OCT2000 bga Initial release by Billy G. Allie.			=
|
>   =20
> =
#----------------------------------------------------------------------=20=

> -+
> ! import os, sys
>   import unittest
>   import types
>   import string
> ***************
> *** 398,404 ****
>
>   class PgSQLTestCases(unittest.TestCase):
>       def setUp(self):
> !         self.cnx =3D PgSQL.connect(database=3D'template1')
>           self.cur =3D self.cnx.cursor()
>   	self.vstr =3D "%(major)d.%(minor)d" % self.cnx.version
>           if self.cnx.version < '7.3':
> --- 398,404 ----
>
>   class PgSQLTestCases(unittest.TestCase):
>       def setUp(self):
> !         self.cnx =3D PgSQL.connect(dsn=3DDSN, database=3D'template1')
>           self.cur =3D self.cnx.cursor()
>   	self.vstr =3D "%(major)d.%(minor)d" % self.cnx.version
>           if self.cnx.version < '7.3':
> ***************
> *** 848,854 ****
>
>   class PgResultSetTests(unittest.TestCase):
>       def setUp(self):
> ! 	self.cnx =3D PgSQL.connect(database=3D'template1')
>   	self.cur =3D self.cnx.cursor()
>
>       def tearDown(self):
> --- 848,854 ----
>
>   class PgResultSetTests(unittest.TestCase):
>       def setUp(self):
> ! 	self.cnx =3D PgSQL.connect(dsn=3DDSN, database=3D'template1')
>   	self.cur =3D self.cnx.cursor()
>
>       def tearDown(self):
> ***************
> *** 983,988 ****
> --- 983,990 ----
>       return test_suite
>
>   def main():
> +     global DSN
> +     DSN =3D os.environ.get("DSN", "")
>       runner =3D unittest.TextTestRunner()
>       runner.run(suite())
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users

Re: [Pypgsql-users] Running installation tests

[Mario R. <ru...@ma...>]

Hello again,

browsing the test sources, i have tried replacing the 2 occurances of
	self.cnx = PgSQL.connect(database='template1')
with
	self.cnx = 
PgSQL.connect(database='template1',user='xxx',password='xxx')
where xxx/xxx are a valid user/passwd on postgres.
Doing this, all 66 tests run OK.

Is this how this test script is supposed to be run?
Shouldn't user/pass be then input (or config) parameters?

Regards, Mario Ruggier



On mardi, jan 21, 2003, at 23:52 Europe/Amsterdam, Mario Ruggier wrote:

> Hello,
>
> am installing pyPgSQL 2.3, and seems to be all OK. When I try to run 
> the tests (as a user
> for whom there is a postgres user with the same name), i get the 
> following error:
>
> ======================================================================
> ERROR: CheckCloseConnection (__main__.PgSQLTestCases)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "test/PgSQLTestCases.py", line 401, in setUp
>     self.cnx = PgSQL.connect(database='template1')
>   File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2118, 
> in connect
>     return Connection(connInfo, client_encoding, unicode_results)
>   File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2215, 
> in __init__
>     raise DatabaseError, m
> DatabaseError: fe_sendauth: no password supplied
>
> and similar error foll all subsequent tests.
>
> How do i supply him the password?
>
> Many thanks, mario
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Pypgsql-users mailing list
> Pyp...@li...
> https://lists.sourceforge.net/lists/listinfo/pypgsql-users
>

[Pypgsql-users] Re: Running installation tests

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

Mario Ruggier <mario=xpR...@pu...> wrote:
> Hello,
> 
> am installing pyPgSQL 2.3, and seems to be all OK. When I try to run 
> the tests (as a user
> for whom there is a postgres user with the same name), i get the 
> following error:
> 
>======================================================================
> ERROR: CheckCloseConnection (__main__.PgSQLTestCases)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "test/PgSQLTestCases.py", line 401, in setUp
>      self.cnx = PgSQL.connect(database='template1')
>    File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2118, 
> in connect
>      return Connection(connInfo, client_encoding, unicode_results)
>    File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2215, 
> in __init__
>      raise DatabaseError, m
> DatabaseError: fe_sendauth: no password supplied
> 
> and similar error foll all subsequent tests.
> 
> How do i supply him the password?

Short answer: in the connect function of the pyPgSQL.PgSQL module. It's all
documented there.

Longer answer: This is a corner of pyPgSQL that needs some work. I think we
should make the database connection for the test cases configurable.
Perhaps by use of a configuration file, perhaps by use of an environment
variable. Any thoughts on this, Billy?

The end of this message is a patch that makes it possible to use an
environment variable called 'DSN' for this, so you can do something like

export DSN="myhost::myuser:mypassword"

or whatever is the way to do it in the shell you're using.

HTH,

Gerhard

Patch follows:

diff -r -C 3 ../pypgsql.orig/test/PgSQLTestCases.py ./test/PgSQLTestCases.py
*** ../pypgsql.orig/test/PgSQLTestCases.py	Wed Jan 22 09:35:08 2003
--- ./test/PgSQLTestCases.py	Wed Jan 22 09:39:48 2003
***************
*** 82,88 ****
  #		ify the test(s) accordingly.				|
  # 01OCT2000 bga Initial release by Billy G. Allie.			|
  #-----------------------------------------------------------------------+
! import sys
  import unittest
  import types
  import string
--- 82,88 ----
  #		ify the test(s) accordingly.				|
  # 01OCT2000 bga Initial release by Billy G. Allie.			|
  #-----------------------------------------------------------------------+
! import os, sys
  import unittest
  import types
  import string
***************
*** 398,404 ****
  
  class PgSQLTestCases(unittest.TestCase):
      def setUp(self):
!         self.cnx = PgSQL.connect(database='template1')
          self.cur = self.cnx.cursor()
  	self.vstr = "%(major)d.%(minor)d" % self.cnx.version
          if self.cnx.version < '7.3':
--- 398,404 ----
  
  class PgSQLTestCases(unittest.TestCase):
      def setUp(self):
!         self.cnx = PgSQL.connect(dsn=DSN, database='template1')
          self.cur = self.cnx.cursor()
  	self.vstr = "%(major)d.%(minor)d" % self.cnx.version
          if self.cnx.version < '7.3':
***************
*** 848,854 ****
  
  class PgResultSetTests(unittest.TestCase):
      def setUp(self):
! 	self.cnx = PgSQL.connect(database='template1')
  	self.cur = self.cnx.cursor()
  
      def tearDown(self):
--- 848,854 ----
  
  class PgResultSetTests(unittest.TestCase):
      def setUp(self):
! 	self.cnx = PgSQL.connect(dsn=DSN, database='template1')
  	self.cur = self.cnx.cursor()
  
      def tearDown(self):
***************
*** 983,988 ****
--- 983,990 ----
      return test_suite
  
  def main():
+     global DSN
+     DSN = os.environ.get("DSN", "")
      runner = unittest.TextTestRunner()
      runner.run(suite())
      

[Pypgsql-users] Running installation tests

[Mario R. <ma...@ru...>]

Hello,

am installing pyPgSQL 2.3, and seems to be all OK. When I try to run 
the tests (as a user
for whom there is a postgres user with the same name), i get the 
following error:

======================================================================
ERROR: CheckCloseConnection (__main__.PgSQLTestCases)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test/PgSQLTestCases.py", line 401, in setUp
     self.cnx = PgSQL.connect(database='template1')
   File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2118, 
in connect
     return Connection(connInfo, client_encoding, unicode_results)
   File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2215, 
in __init__
     raise DatabaseError, m
DatabaseError: fe_sendauth: no password supplied

and similar error foll all subsequent tests.

How do i supply him the password?

Many thanks, mario

Re: [Pypgsql-users] windows error "no buffer space available"

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

> As a side not, not related to your problem, the previous 3 lines should be 
> written as:
>   cmd = "SELECT data FROM doc_obj WHERE oid=%s"
>   try:
> 	cursor.execute(cmd, anObjID)
True enough. I didn't audit the entire code base yet as we
have supported other db-api drivers in the past. Mind you, we
would still like to but db api 2.0 does not include
Listen/Notify to the best of my knowledge and we need it.
Apart from escaping in bytea and PgArray (the other reason we
now focus in pypgsql) it shouldn't make much difference
either?

>> aFile.write(str(cursor.fetchone()[0]))
> This will read all of data for anObjID into memory before writing it to the 
> file.  It is possible that you are running out of memory on the Win9X platform.
May be true. However, this same machine scanned the same
picture just fine.

> Is there a reason you didn't use large objects instead of bytea columns?  With 
a) when I started out I found the interface awkward and
   couldn't get my brain wrapped around it
b) it doesn't feel very natural
c) bytea is supposed to become even more like lo_object in
   that it is supposed to gain chunk-read capabilities, too
d) can one lo_import remotely ?  this is crucial

> large objects, you can read and write the data in 'chunks' to avoid consuming 
> large quantities of memory.
I know, see c) above.

> Does the problem also exist on Windows NT4, 2000 or XP?
Don't have the chance to test as I don't have those platforms
available. Apart from being an Open Source shop with limited
funding we aren't even a shop at all...  Just some insane MDs
hacking Python :-)

> This may be a Windows 98SE only problem.  If it is, does Windows 98SE have to 
> be one of the supported platforms?
Yes.

> A work-around would be to use large objects and read/write the data in chunks 
> so as not to require such large buffers.  I can, if requested, give some 
> sample code that will illustrate the methods to use.
That would be very helpful. I may not be able to use it right
away but it'll help me get a handle on it.

Thanks !

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

Re: [Pypgsql-users] windows error "no buffer space available"

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

Karsten Hilbert wrote:
> Hello !
> 
> We are using pypgsql in the medical practice management project
> GnuMed (www.gnumed.org). On task of GnuMed is to store
> documents relevant to patients. We have the following code
> retrieving document data from a bytea column:
> 
> #-------------------
> # start our transaction (done implicitely by defining a cursor)
> cursor = aConn.cursor()
> # retrieve object
> cmd = "SELECT data FROM doc_obj WHERE oid='%s'" % (anObjID)
> try:
> 	cursor.execute(cmd)
As a side not, not related to your problem, the previous 3 lines should be 
written as:
  cmd = "SELECT data FROM doc_obj WHERE oid=%s"
  try:
	cursor.execute(cmd, anObjID)

> except:
> 	_log.LogException("cannot SELECT doc_obj", sys.exc_info())
> 	return None
> # cDocument.metadata->objects->file name
> obj['file name'] = tempfile.mktemp()
> aFile = open(obj['file name'], 'wb+')
> # it would be a fatal error to see more than one result as oids are supposed 
> to be unique
> aFile.write(str(cursor.fetchone()[0]))

This will read all of data for anObjID into memory before writing it to the 
file.  It is possible that you are running out of memory on the Win9X platform.
Is there a reason you didn't use large objects instead of bytea columns?  With 
large objects, you can read and write the data in 'chunks' to avoid consuming 
large quantities of memory.

> aFile.close()
> # close our connection
> cursor.close()
> #-------------------
> 
> This works like a charm on Linux. On Win98SE, however,
> we get (consistent) errors one some documents. Those docs are
> large bitmaps, about 6 MB in size.
> 
> pyPgSQL version: pypgsql-2-3.Win32.-py2.2.exe  13.12.02
> 
> Now, if you take a look at our log below you'll see the
> following error:
> 
> OperationalError: could not receive data from server: No buffer space availab
> le (0x00002747/10055)
> 
> Googling around a bit reveals that this error originates in
> the Windows Socket API and has to do with (who'd have thunk
> it) TCP transmit buffers.
> 

Does the problem also exist on Windows NT4, 2000 or XP?
This may be a Windows 98SE only problem.  If it is, does Windows 98SE have to 
be one of the supported platforms?

> 
> However, the only mention of a problem remotely sounding like
> ours on this mailing list is here:
>  http://sourceforge.net/mailarchive/message.php?msg_id=1082358
> 
> I wonder if anyone can offer any insight, assure us it's a
> known bug on the TODO list (couldn't verify that myself), or
> point us to the odd registry setting we need to tweak

A work-around would be to use large objects and read/write the data in chunks 
so as not to require such large buffers.  I can, if requested, give some 
sample code that will illustrate the methods to use.

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

[Pypgsql-users] windows error "no buffer space available"

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

Hello !

We are using pypgsql in the medical practice management project
GnuMed (www.gnumed.org). On task of GnuMed is to store
documents relevant to patients. We have the following code
retrieving document data from a bytea column:

#-------------------
# start our transaction (done implicitely by defining a cursor)
cursor = aConn.cursor()
# retrieve object
cmd = "SELECT data FROM doc_obj WHERE oid='%s'" % (anObjID)
try:
	cursor.execute(cmd)
except:
	_log.LogException("cannot SELECT doc_obj", sys.exc_info())
	return None
# cDocument.metadata->objects->file name
obj['file name'] = tempfile.mktemp()
aFile = open(obj['file name'], 'wb+')
# it would be a fatal error to see more than one result as oids are supposed to be unique
aFile.write(str(cursor.fetchone()[0]))
aFile.close()
# close our connection
cursor.close()
#-------------------

This works like a charm on Linux. On Win98SE, however,
we get (consistent) errors one some documents. Those docs are
large bitmaps, about 6 MB in size.

pyPgSQL version: pypgsql-2-3.Win32.-py2.2.exe  13.12.02

Now, if you take a look at our log below you'll see the
following error:

OperationalError: could not receive data from server: No buffer space available (0x00002747/10055)

Googling around a bit reveals that this error originates in
the Windows Socket API and has to do with (who'd have thunk
it) TCP transmit buffers.

 http://www.cit.cornell.edu/helpdesk/win/email/eud10055.html
 http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?fn=db2tcp.htm
 http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_error_codes_2.asp

However, the only mention of a problem remotely sounding like
ours on this mailing list is here:
 http://sourceforge.net/mailarchive/message.php?msg_id=1082358

I wonder if anyone can offer any insight, assure us it's a
known bug on the TODO list (couldn't verify that myself), or
point us to the odd registry setting we need to tweak.

Regards,

Karsten Hilbert, MD
GnuMed i18n coordinator

PS: Yes, that's a real patient. Now go sue me :-))

PPS: Here's the complete log:
#===================================================================================================
2003-01-12 16:15:23 ------------------------------------------------------------
2003-01-12 16:15:23 [INFO]  (.\modules\gmLog.py::__init__:357): SECURITY: initial log level is [INFO]  
2003-01-12 16:15:23 [INFO]  (.\modules\gmLog.py::SetAllLogLevels:241): SECURITY: log level change from [INFO]   to [DATA]  
2003-01-12 16:15:23 [DATA]  (.\gmShowMedDocs.py::Main:28): $Revision: 1.4 $
2003-01-12 16:15:23 [DATA]  (.\modules\gmCLI.py::Main:125): $Revision: 1.8 $
2003-01-12 16:15:23 [DATA]  (.\modules\gmCLI.py::_preparse_cmdline:65): unparsed command line is >>.\gmShowMedDocs.py --conf-file=.\gnumed-archive.conf --text-domain=gnumed-archive<<
2003-01-12 16:15:23 [DATA]  (.\modules\gmCLI.py::_parse_opts:118): command line arguments: {'--text-domain': 'gnumed-archive', '--conf-file': '.\\gnumed-archive.conf'}
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::Main:185): $Revision: 1.21 $
2003-01-12 16:15:23 [INFO]  (.\modules\gmI18N.py::install_domain:77): text domain is "gnumed-archive"
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:84): $(LANGUAGE) is not set
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:90): $(LC_ALL) is not set
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:96): $(LC_MESSAGES) is not set
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:100): $(LANG) is set to "de_DE@euro"
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:105): Searching message catalog file.
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:121): Looking behind environment variable $(GMSHOWMEDDOCS_DIR).
2003-01-12 16:15:23 [INFO]  (.\modules\gmI18N.py::install_domain:136): Environment variable GMSHOWMEDDOCS_DIR is not set.
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:143): Looking in application level directory [C:\Programme\GNUmedArchive\locale].
2003-01-12 16:15:23 [WARN]  (.\modules\gmI18N.py::install_domain:154): The application level locale directory [C:\Programme\GNUmedArchive\locale] does not exist. Cannot install textdomain from there.
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:158): Looking in application level directory [C:\Programme\GNUmedArchive\client\locale].
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::install_domain:163): Found message catalog.
2003-01-12 16:15:23 [DATA]  (.\modules\gmI18N.py::Main:198): local time format set to "%Y-%m-%d  %H:%M:%S"
2003-01-12 16:15:23 [DATA]  (.\modules\gmCfg.py::Main:819): $Revision: 1.33 $
2003-01-12 16:15:23 [DATA]  (.\modules\gmCfg.py::__get_conf_name:546): (<aDir=None>, <aName=None>)
2003-01-12 16:15:23 [DATA]  (.\modules\gmCfg.py::__get_conf_name:569): --conf-file=.\gnumed-archive.conf
2003-01-12 16:15:23 [DATA]  (.\modules\gmCfg.py::__get_conf_name:572): Found config file [.\gnumed-archive.conf].
2003-01-12 16:15:23 [DATA]  (.\modules\gmCfg.py::__parse_conf_file:656): parsing config file [.\gnumed-archive.conf]
2003-01-12 16:15:24 [DATA]  (.\modules\gmBackendListener.py::Main:112): $Revision: 1.5 $
2003-01-12 16:15:24 [INFO]  (.\modules\gmPG.py::Main:77): DBMS "Postgres" via DB-API module "<module 'pyPgSQL.PgSQL' from 'C:\PYTHON22\lib\site-packages\pyPgSQL\PgSQL.pyc'>": API level 2.0, thread safety 1, parameter style "pyformat"
2003-01-12 16:15:24 [DATA]  (.\modules\gmPG.py::Main:572): $Revision: 1.29 $
2003-01-12 16:15:25 [INFO]  (.\gmShowMedDocs.py::Main:346): starting display handler
2003-01-12 16:15:25 [DATA]  (.\modules\docDatabase.py::__init__:20): instantiating befund database connection object
2003-01-12 16:15:25 [DATA]  (.\modules\gmPG.py::__connect:287): host:port=192.168.1.1:5432, db=gm-archive, user=papa, pw=??, opts=, tty=
2003-01-12 16:15:26 [INFO]  (.\modules\docDatabase.py::connect:40): backend connection successfully established
2003-01-12 16:15:26 [DATA]  (.\modules\gmPG.py::GetConnection:133): requesting RO connection to service [default]
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::__load_from_xdt:100): found item [last name]: Pfizer
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::__load_from_xdt:100): found item [first name]: Bernie
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::__load_from_xdt:100): found item [date of birth]: 21011928
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::__load_from_xdt:100): found item [gender]: 2
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::__load_from_xdt:132): Bernie Pfizer (f), 19280121 (DE)
2003-01-12 16:15:26 [INFO]  (.\modules\docPatient.py::getIDfromGNUmed:210): getting patient ID from GNUmed compatible database
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::getIDfromGNUmed:227): matching patient ID(s): [[8]]
2003-01-12 16:15:26 [INFO]  (.\gmShowMedDocs.py::__init__:99): Making document tree for patient with ID 8
2003-01-12 16:15:26 [INFO]  (.\modules\docPatient.py::getDocsFromGNUmed:252): getting documents from GNUmed compatible database
2003-01-12 16:15:26 [DATA]  (.\modules\docPatient.py::getDocsFromGNUmed:277): document IDs: [[1]]
2003-01-12 16:15:26 [DATA]  (.\modules\docDocument.py::__init__:49): Instantiated.
2003-01-12 16:15:26 [INFO]  (.\modules\docDocument.py::loadMetaDataFromGNUmed:143): loading stage 1 (document) metadata from GnuMed compatible database
2003-01-12 16:15:26 [DATA]  (.\modules\docDocument.py::loadMetaDataFromGNUmed:182): Meta data: {'comment': 'CT-Sch\xe4del', 'date': '2002-10-24', 'objects': {19648: {'comment': None, 'index': 1}}, 'reference': '3.20021201-143103', 'patient id': 8, 'type': 110, 'id': 1}
2003-01-12 16:15:30 [DATA]  (.\gmShowMedDocs.py::OnActivate:205): User selected object 19648 from document 1
2003-01-12 16:15:30 [DATA]  (.\gmShowMedDocs.py::OnActivate:210): working into directory 'c:\gmtmp\export'
2003-01-12 16:15:30 [DATA]  (.\gmShowMedDocs.py::OnActivate:215): document: {'comment': 'CT-Sch\xe4del', 'date': '2002-10-24', 'objects': {19648: {'comment': None, 'index': 1}}, 'reference': '3.20021201-143103', 'patient id': 8, 'type': 110, 'id': 1}
2003-01-12 16:15:30 [INFO]  (.\modules\docDocument.py::exportObjFromGNUmed:321): exporting object from GnuMed compatible database
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): cannot SELECT doc_obj
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): exception type : libpq.OperationalError
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): exception value: could not receive data from server: No buffer space available (0x00002747/10055)

2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): Traceback (most recent call last):<#10-0x0A-lf>
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353):   File ".\modules\docDocument.py", line 351, in exportObjFromGNUmed<#10-0x0A-lf>    cursor.execute(cmd)<#10-0x0A-lf>
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353):   File "C:\PYTHON22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2978, in execute<#10-0x0A-lf>    self.__makedesc__()<#10-0x0A-lf>
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353):   File "C:\PYTHON22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2710, in __makedesc__<#10-0x0A-lf>    _tn, _pl, _ia, _bt = _cache.getTypeInfo(_typ)<#10-0x0A-lf>
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353):   File "C:\PYTHON22\Lib\site-packages\pyPgSQL\PgSQL.py", line 799, in getTypeInfo<#10-0x0A-lf>    _res = self.__conn.conn.query("SELECT typname, -1 , typelem "<#10-0x0A-lf>
2003-01-12 16:15:38 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): OperationalError: could not receive data from server: No buffer space available (0x00002747/10055)<#10-0x0A-lf><#10-0x0A-lf>
2003-01-12 16:15:38 [ERROR] (.\gmShowMedDocs.py::OnActivate:219): Cannot export object (19648) data from database !
2003-01-12 16:15:56 [DATA]  (.\gmShowMedDocs.py::OnActivate:205): User selected object 19648 from document 1
2003-01-12 16:15:56 [DATA]  (.\gmShowMedDocs.py::OnActivate:210): working into directory 'c:\gmtmp\export'
2003-01-12 16:15:56 [DATA]  (.\gmShowMedDocs.py::OnActivate:215): document: {'comment': 'CT-Sch\xe4del', 'date': '2002-10-24', 'objects': {19648: {'comment': None, 'index': 1}}, 'reference': '3.20021201-143103', 'patient id': 8, 'type': 110, 'id': 1}
2003-01-12 16:15:56 [INFO]  (.\modules\docDocument.py::exportObjFromGNUmed:321): exporting object from GnuMed compatible database
2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): cannot SELECT doc_obj
2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): exception type : libpq.OperationalError
2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): exception value: could not receive data from server: No buffer space available (0x00002747/10055)

2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): Traceback (most recent call last):<#10-0x0A-lf>
2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353):   File ".\modules\docDocument.py", line 351, in exportObjFromGNUmed<#10-0x0A-lf>    cursor.execute(cmd)<#10-0x0A-lf>
2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353):   File "C:\PYTHON22\Lib\site-packages\pyPgSQL\PgSQL.py", line 2951, in execute<#10-0x0A-lf>    self.conn.conn.query('ROLLBACK WORK')<#10-0x0A-lf>
2003-01-12 16:15:56 [PANIC] (.\modules\docDocument.py::exportObjFromGNUmed:353): OperationalError: could not receive data from server: No buffer space available (0x00002747/10055)<#10-0x0A-lf><#10-0x0A-lf>
2003-01-12 16:15:56 [ERROR] (.\gmShowMedDocs.py::OnActivate:219): Cannot export object (19648) data from database !
2003-01-12 16:16:07 [INFO]  (.\modules\docDatabase.py::disconnect:54): releasing befund database connection
2003-01-12 16:16:07 [INFO]  (.\gmShowMedDocs.py::Main:362): closing display handler

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

Re: [Pypgsql-users] typprtlen

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

* Oliver Vecernik <vec...@ao...> [2003-01-09 09:43 +0100]:
> Hi!
> 
> I tried to use PgSQL on Debian/Woody and received following error:
> 
> Python 2.1.3 (#1, Sep  7 2002, 15:29:56)
> [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
> Type "copyright", "credits" or "license" for more information.
> >>> from pyPgSQL import PgSQL
> >>> cx = PgSQL.connect('p200::test')
> >>> cu = cx.cursor()
> >>> cu.execute("select * from t1")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.1/site-packages/pyPgSQL/PgSQL.py", line 2157, 
> in execute
>     self.__makedesc__()
>   File "/usr/lib/python2.1/site-packages/pyPgSQL/PgSQL.py", line 1892, 
> in __makedesc__
>     _tn, _pl, _ia, _bt = _cache.getTypeInfo(_typ)
>   File "/usr/lib/python2.1/site-packages/pyPgSQL/PgSQL.py", line 576, 
> in getTypeInfo
>     _res = self.__conn.conn.query("SELECT typname, typprtlen, typelem "
> libpq.OperationalError: ERROR:  Attribute "typprtlen" not found
> 
> >>>
> 
> 
> ii  python-pgsql   2.0-3.1        A Python DB-API 2.0 interface to 
> PostgreSQL
> 
> Am I doing something wrong, or is this a broken package in Debian?

You're using pyPgSQL against a PostgreSQL 7.3.x database. pyPgSQL,
however, supports a Pg 7.3 backend only in the latest released version
(pyPgSQL 2.3).

So, for the moment you need to compile pyPgSQL yourself, as even the
Debian unstable package seems to still be a 2.3-beta1.

If you want to do a quick hack in your pyPgSQL 2.0 package instead, you
can try to change the typprtlen field in the select to NULL.

Gerhard
-- 
Favourite database:             http://www.postgresql.org/
Favourite programming language: http://www.python.org/
Combine the two:                http://pypgsql.sf.net/
Embedded database for Python:   http://pysqlite.sf.net/