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

Re: [Pypgsql-users] Upgrade to pg7.2.1 broke apps

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

* James Thompson <ja...@gn...> [2002-05-02 11:28 -0500]:
> 
> Hello,
> 
> I recently moved from pg 7.1.3 to 7.2.1.  Now my win32 and solaris app
> that used pypgsql has become very flaky with regard to pulling data from
> the database.  The only tables that seem affected are those with text
> fields in them.  The app still seems to work using either pygresql or
> psycopg.

What is the problem you see? Wrong characters in the text fields?

> I have tried rebuilding the postgresql client libs on the solaris box then
> reinstalling pypgsql.  This did not solve the problem.
> 
> Any Ideas?

Not currently, but I'll try to debug this. I need additional data,
however.

Could you please construct a minimal test case that shows this problem,
including:
- the schema of the table
- one or more entries in the table where this problem occurs
- the pyPgSQL code you use to query the table

That would help us to look at this problem, try to reproduce it and fix
the problem in pyPgSQL.

You can then post this to the list or submit it as a bug at Sourceforge
(if you submit it as a bug at SF, please drop me a note, too).

You're using the 2.0 release of pyPgSQL, right?

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] Upgrade to pg7.2.1 broke apps

[James T. <ja...@gn...>]

Hello,

I recently moved from pg 7.1.3 to 7.2.1.  Now my win32 and solaris app
that used pypgsql has become very flaky with regard to pulling data from
the database.  The only tables that seem affected are those with text
fields in them.  The app still seems to work using either pygresql or
psycopg.

I have tried rebuilding the postgresql client libs on the solaris box then
reinstalling pypgsql.  This did not solve the problem.

Any Ideas?

Thanks
James

[Pypgsql-users] FAQ

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

There's now a FAQ on http://pypgsql.sf.net/ This is a true FAQ in the
sense that each question was asked at least once :)

Thanks to Docbook, it's available in HTML, PDF and Postscript.

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] Thanks and unicode and YAML

[Clark C . E. <cc...@cl...>]

Since I didn't see alot of traffic on this list, I 
thought I'd mention that we have had great success
with Billy's glue.  I've had boxes up for 3+ months
now running PostgreSQL 7.1, Python 2.1, and Webware
using pyPgSQL.  This with some pretty heavy usage.

Speaking of unicode.  I'd love unicode support.  If
we were were turning a profit, I'd even offer to support
development; but alas, not quite.  In about two weeks
or so, I'll spend some time and install your patch on
our demo box to see how well it goes!

BTW, you may be interested to know about YAML, an
alternative to XML that alot of us have been working
on... the python binding is progressing nicely; as soon
as this is done, I'll be focusing on the PostgreSQL 
binding so one could load/dump PostgreSQL data to YAML.

Best,

Clark
-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software

Re: [Pypgsql-users] Unicode, take 2

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

* Adam Buraczewski <ad...@po...> [2002-04-18 00:25 +0200]:
> Is it really necessary to pass the information about encoding twice
> (once for PgSQL and second time for PostgreSQL)?

No, that was just to reduce implementation effort and maintenance
problems with new encodings supported by PostgreSQL.

> Personally I'd like
> to see PgSQL deal with it completely: the module should send an
> appropriate "set client_encoding" command to PostgreSQL automatically,
> just after connecting to the database and before beginning of the
> first transaction.  I will insist on such behaviour, especially
> because PostgreSQL 7.3 will reset all SET commands to their initial
> states on transaction rollback (vide discussion on pgsql-hackers
> several days ago).

Ok, I agree. I think, however, we need Billy's opinion on how to
implement this. Btw. I couldn't find anything about the issue you
mention in the web archives of pgsql-hackers. Could you post the URL of
the relevant thread/message?

> The only thing which should be done is a simple map, which will
> convert Python encoding names to PostgreSQL encoding names.  I am not
> right? :)

Of course you are :) And this is how it was done in my first
implementation, it just adds some complexity that I thought is best left
out. But you convinced me I should add this feature again.

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] Unicode, take 2

[Adam B. <ad...@po...>]

Hi,

> Cc-ing Adam, because he showed interest in this topic.

:^)

I am really impressed by the work You've done!  I like this patch very
much and I certainly will use this new featue in my projects.  I
promise to test it thoroughly, however not before weekend, I'm afraid.
I'd like also to rewrite my ISO 8859-2 tests for pyPgSQL, which I
wrote several months ago and submitted to Billy G. Allie.

> A short example from the testcases to whet your appetite:
>=20
>     text1 =3D unicode("=D6sterreich-", "latin1")
>     text2 =3D unicode("Ungarn", "ascii")
>=20
>     conn =3D PgSQL.connect(host=3Dhost, database=3Ddbname, client_encod=
ing=3D("utf-8",), unicode_results=3D1)
>     cursor =3D conn.cursor()
>     cursor.execute("set client_encoding to unicode")

Is it really necessary to pass the information about encoding twice
(once for PgSQL and second time for PostgreSQL)?  Personally I'd like
to see PgSQL deal with it completely: the module should send an
appropriate "set client_encoding" command to PostgreSQL automatically,
just after connecting to the database and before beginning of the
first transaction.  I will insist on such behaviour, especially
because PostgreSQL 7.3 will reset all SET commands to their initial
states on transaction rollback (vide discussion on pgsql-hackers
several days ago).

The only thing which should be done is a simple map, which will
convert Python encoding names to PostgreSQL encoding names.  I am not
right? :)

Regards,

--=20
Adam Buraczewski <ad...@po...> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?

[Pypgsql-users] Unicode, take 2

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

of 3 :)

Cc-ing Adam, because he showed interest in this topic.

I've resumed my work on integrating Unicode support into pyPgSQL, an
updated patch can be found at:

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

I'm pretty confident that this is approach will work out in the end, and
the few tests that I've written and that are included in the patch work
fine so far.

*Especially* useful would be if those interested in Unicode/i18n support
could try out this patch and comment on the interface. And I'd be really
grateful if you could write additional testcases that exercise your
native language and preferred client (and perhaps even server)
encodings.

I suggest to keep the discussion on the mailing list, if possible.

A short example from the testcases to whet your appetite:

    text1 = unicode("Österreich-", "latin1")
    text2 = unicode("Ungarn", "ascii")

    conn = PgSQL.connect(host=host, database=dbname, client_encoding=("utf-8",), unicode_results=1)
    cursor = conn.cursor()
    cursor.execute("set client_encoding to unicode")
    cursor.execute(u"""
    CREATE FUNCTION concat_text (TEXT, TEXT) RETURNS TEXT AS '
    BEGIN
    RETURN $1 || $2;
    END;
    'LANGUAGE 'plpgsql';
    """)
    cursor.callproc(u"concat_text", text1, text2)
    result = cursor.fetchone()[0]
    self.failUnless(result == text1 + text2, "procedure didn't return the two strings concatenated")

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] cursor.rowcount

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

Martin Dengler wrote:
> Hi Guys,
> 
> i got a problem with cursor.rowcount. After a select-stmt is executed and
> there is definitly a result, cursor.rowcount always has the value -1 ? Is thi
> s
> not implemented yet ? 
> 
> my setup:
> WIN ME, postgre v.7.1.3, ActivePython v.2.1.212, PgSQL v. 1.4
> 
> any ideas ?

By default, PgSQL uses PostgreSQL Portals (i.e. cursors).  As a result of
this, PgSQL doesn't know how many rows resulted from the query until they
are fetched.  (Note: rowcount will be set to the number of rows returned by
the fectchXXX() method.  If you fecthone(), rowcount will be 1.)

There are a couple of ways to get the number of rows returned by a query:

1.  Do a fetchall().  rowcount will then be set to the number of rows
    retrieved.

2.  Set PgSQL.noPostgresCursor to 1.  This will prevent PgSQL from using
    PostgreSQL Portals (which will result in the entire result set being
    read into memory).  Rowcount will be set to the number of rows
    retrieved.

3.  Execute a "select count(*) ..." to get the number of rows.

4.  Re-evaluate why you need to know the number of rows before processing
    the results.
___________________________________________________________________________
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |

[Pypgsql-users] cursor.rowcount

[Martin D. <mar...@gm...>]

Hi Guys,

i got a problem with cursor.rowcount. After a select-stmt is executed and
there is definitly a result, cursor.rowcount always has the value -1 ? Is this
not implemented yet ? 

my setup:
WIN ME, postgre v.7.1.3, ActivePython v.2.1.212, PgSQL v. 1.4

any ideas ?

MD

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Pypgsql-users] Decoding resultSet

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

Le 09/03/02 à 12:31, Ellen Spertus écrivit:
> I'm having trouble decoding a resultSet from a query:
> >>> from pyPgSQL.libpq import *

libpq is the low-level API. If you don't have a good reason to use it,
don't :) Much better is to use the DB-API interface in pyPgSQL.PgSQL.
Then, you can also stay fairly portable across databases.

> [snip]

Using the DB-API interface, your code would look like:

from pyPgSQL import PgSQL

# Connect to the default database with database=user=$USER
db = PgSQL.connect()
# using no default values:
# PgSQL.connect(host=..., database=..., user=..., password=...)

# Create a cursor object (that is implicitely wrapped in a transaction)
cursor = db.cursor()

# Execute the query
cursor.execute("select count(*) from test")

# Fetch one row (here, the only one) from the resultset,
# and select the first column from that row
numrows = cursor.fetchone()[0]

> [...] Also, can anyone point me to any documentation for pypgsql?  I
> haven't been able to find it.

AFAIK the only documentation there is is in the README, the docstrings,
and the examples in the examples directory.

But as pyPgSQL "only" is an implementation of the Python DB-API 2.0 for
PostgreSQL, so you can use the documentation available for the DB-API,
for example:

- the specification itself:
  http://www.python.org/topics/database/DatabaseAPI-2.0.html
- an article by Andrew Kuchling:
  http://www.amk.ca/python/writing/DB-API.html

All documentation you can find for other DB-API modules like MySQLdb
also mostly applies to pyPgSQL.PgSQL. You only have to import a
different module and the way the connect method works differs :)

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] Decoding resultSet

[Ellen S. <sp...@mi...>]

I'm having trouble decoding a resultSet from a query:
 >>> from pyPgSQL.libpq import *
 >>> c = PQconnectdb("...")
 >>> c.sendQuery("SELECT COUNT(thread_id) FROM thread")
 >>> d = c.getResult()
 >>> print d.ntuples
1
 >>> print d[0]
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: unsubscriptable object
 >>> print d.getValue(0)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: getValue

What is the right way to extract the result?

When I try making the same query directly in postgres, it works:
etest=> select COUNT(thread_id) FROM thread;
  count
-------
      0
(1 row)

Also, can anyone point me to any documentation for pypgsql?  I haven't been 
able to find it.

Thank you.

Ellen Spertus

Re: [Pypgsql-users] Special characters

[Adam B. <ad...@po...>]

> how should I handle case when I have special chars included
> into value text or character varying.

The library can handle such situations automatically.  However, You
should allow it to construct final SQL queries itself (don't use
Python's % operator).  Look at the code below:

	from pyPgSQL import PgSQL
	dbc = PgSQL.connect( ... )
	c = dbc.cursor()
	a = "string'with\\quotes'\"' and\r\n\t %stuff%"
	b = None
	c = 123.45
	c.execute("insert into tab values (%s, %s, %s);",
	          a, b, c);

What happens here?  First passed value is a string, so all special
characters are automatically backslashed and the whole value is
enclosed between quotes (').  The second one is None, so it is
converted to SQL's null.  The third is passed almost as-is, because
it's a number.

The best You can do is looking at the source code of PgSQL module and
DBI 2.0 standard (it's easy to find it in Python website), the
full explanation is right there.

Regards,

-- 
Adam Buraczewski <ad...@po...> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?

Re: [Pypgsql-users] Special characters

[Christian T. <ct...@go...>]

Hi.


This is a question that *should* be only postgres specific,
but i don't know exactly:

THe only special character i can think of having troubles beeing inserted
is - as you showed down in your dictionary example, the ' quote, which you
should escape with a double ' ('') because postgres uses ' to start and finish strings.

hope that helps ...


christian.

On Sun, Mar 03, 2002 at 08:26:06PM -0800, Aleksandar Kacanski wrote:
> I work with the pypgsql and love the library. It is very
> well designed peace of code and works extremely well for
> me.
> However I have question that I need help with.
> I am designing web interface in python to accommodate
> automation of the product database.
> Everything works flawlessly, but special characters will
> not pass in the insert SQL statement.
> how should I handle case when I have special chars included
> into value text or character varying.
> I would pool something like this: dict = {'key':"value's"}
> which will get me error back.
> do I need to deal with the special chars prior to adding
> values to  execute statement, or I am missing something on
> the design of the table - fields
> 
> Please send response to kac...@ya...
> 
> Thanks

-- 
Christian Theune - ct...@go...
gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt
tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981

reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])

[Pypgsql-users] Special characters

[Aleksandar K. <kac...@ya...>]

I work with the pypgsql and love the library. It is very
well designed peace of code and works extremely well for
me.
However I have question that I need help with.
I am designing web interface in python to accommodate
automation of the product database.
Everything works flawlessly, but special characters will
not pass in the insert SQL statement.
how should I handle case when I have special chars included
into value text or character varying.
I would pool something like this: dict = {'key':"value's"}
which will get me error back.
do I need to deal with the special chars prior to adding
values to  execute statement, or I am missing something on
the design of the table - fields

Please send response to kac...@ya...

Thanks


=====
------
     *  "Last night I dreamed I ate a ten-pound marshmallow, and when I woke up the pillow was gone."

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: [Pypgsql-users] setup on SuSE 7.3

[Oliver V. <vec...@ao...>]

Gerhard H=E4ring wrote:

> Le 18/02/02 ? 12:03, Oliver Vecernik =E9crivit:
>=20
>>Meanwhile I installed the driver and ran the tests.
>>
>>...........................EF......................
>>=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: CheckWeakReference1 (__main__.PgSQLTestCases)
>>----------------------------------------------------------------------
>>Traceback (most recent call last):
>>  File "test/PgSQLTestCases.py", line 333, in CheckWeakReference1
>>    self.assertEquals(len(self.cnx.cursors.data.keys()), 0,
>>AttributeError: data
>>=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: CheckWeakReference2 (__main__.PgSQLTestCases)
>>----------------------------------------------------------------------
>>Traceback (most recent call last):
>>  File "test/PgSQLTestCases.py", line 338, in CheckWeakReference2
>>    self.failUnlessRaises(PgSQL.InterfaceError, self.cur.close)
>>  File "/var/tmp/python-root//usr/lib/python2.1/unittest.py", line 266,=
=20
>>in failUnlessRaises
>>    raise self.failureException, excName
>>AssertionError: InterfaceError
>>----------------------------------------------------------------------
>>Ran 51 tests in 2.419s
>>
>>FAILED (failures=3D1, errors=3D1)
>>
>>
>>What does that mean?
>>
>=20
> The 'what' is not difficult: it checks wether there really aren't any
> cursors left for the test connection.
>=20
> As for the 'why', I currently have no idea. You haven't changed anythin=
g
> in the PgSQLTestCases.py file except maybe the line building the
> database connection, did you?

I didn't change anything in PgSQLTestCases.py, I simply started it to=20
check my installation.

Oliver

Re: [Pypgsql-users] setup on SuSE 7.3

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

Le 18/02/02 ? 12:03, Oliver Vecernik écrivit:
> Meanwhile I installed the driver and ran the tests.
> 
> ...........................EF......................
> ======================================================================
> ERROR: CheckWeakReference1 (__main__.PgSQLTestCases)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "test/PgSQLTestCases.py", line 333, in CheckWeakReference1
>     self.assertEquals(len(self.cnx.cursors.data.keys()), 0,
> AttributeError: data
> ======================================================================
> FAIL: CheckWeakReference2 (__main__.PgSQLTestCases)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "test/PgSQLTestCases.py", line 338, in CheckWeakReference2
>     self.failUnlessRaises(PgSQL.InterfaceError, self.cur.close)
>   File "/var/tmp/python-root//usr/lib/python2.1/unittest.py", line 266, 
> in failUnlessRaises
>     raise self.failureException, excName
> AssertionError: InterfaceError
> ----------------------------------------------------------------------
> Ran 51 tests in 2.419s
> 
> FAILED (failures=1, errors=1)
> 
> 
> What does that mean?

The 'what' is not difficult: it checks wether there really aren't any
cursors left for the test connection.

As for the 'why', I currently have no idea. You haven't changed anything
in the PgSQLTestCases.py file except maybe the line building the
database connection, did you?

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] setup on SuSE 7.3

[Oliver V. <vec...@ao...>]

Gerhard H=E4ring wrote:

Thank you for your immediate reply!

> Le 18/02/02 ? 09:52, Oliver Vecernik =E9crivit:
>=20
>>Hi,
>>
>>I'm trying to install pypgsql-2.0.tar.gz on a SuSE 7.3 Linux box. I=20
>>started my build with:
>>
>>python setup.py build
>>
>>and got following error:
>>
>>gcc: unrecognized option `-R/usr/local/pgsql/lib'
>>
>=20
> This is a warning, not an error.
>=20
> Btw. SuSE installs PostgreSQL somewhere else, not /usr/local/pgsql. But=

> maybe you've installed PostgreSQL from a different source or compiled i=
t
> yourself. To use pyPgSQL with SuSE's PostgreSQL RPMs, you'd need to
> change the paths in setup.py.


You're absolutely right. I compiled 7.1.3 myself. Meanwhile I installed=20
the driver and ran the tests.

=2E..........................EF......................
=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: CheckWeakReference1 (__main__.PgSQLTestCases)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test/PgSQLTestCases.py", line 333, in CheckWeakReference1
     self.assertEquals(len(self.cnx.cursors.data.keys()), 0,
AttributeError: data
=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: CheckWeakReference2 (__main__.PgSQLTestCases)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "test/PgSQLTestCases.py", line 338, in CheckWeakReference2
     self.failUnlessRaises(PgSQL.InterfaceError, self.cur.close)
   File "/var/tmp/python-root//usr/lib/python2.1/unittest.py", line 266, =

in failUnlessRaises
     raise self.failureException, excName
AssertionError: InterfaceError
----------------------------------------------------------------------
Ran 51 tests in 2.419s

FAILED (failures=3D1, errors=3D1)


What does that mean?

Best Regards,
Oliver

Re: [Pypgsql-users] setup on SuSE 7.3

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

Le 18/02/02 ? 09:52, Oliver Vecernik écrivit:
> Hi,
> 
> I'm trying to install pypgsql-2.0.tar.gz on a SuSE 7.3 Linux box. I 
> started my build with:
> 
> python setup.py build
> 
> and got following error:
> 
> gcc: unrecognized option `-R/usr/local/pgsql/lib'

This is a warning, not an error.

Btw. SuSE installs PostgreSQL somewhere else, not /usr/local/pgsql. But
maybe you've installed PostgreSQL from a different source or compiled it
yourself. To use pyPgSQL with SuSE's PostgreSQL RPMs, you'd need to
change the paths in setup.py.

> I use following version of gcc:
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
> gcc version 2.95.3 20010315 (SuSE)
> 
> 
> What am I doing wrong?

Nothing. This is a gcc bug for which there's an (ugly) workaround in the
latest Python CVS (post 2.2), btw. If you've really installed PostgreSQL
in that directory, you can point LD_LIBRARY_PATH to the directory, or
add it to your file /etc/ld.so.conf.

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] setup on SuSE 7.3

[Oliver V. <vec...@ao...>]

Hi,

I'm trying to install pypgsql-2.0.tar.gz on a SuSE 7.3 Linux box. I 
started my build with:

python setup.py build

and got following error:

gcc: unrecognized option `-R/usr/local/pgsql/lib'

I use following version of gcc:
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
gcc version 2.95.3 20010315 (SuSE)


What am I doing wrong?

Regards,
Oliver

[Pypgsql-users] New user

[<san...@at...>]

Hello!  Im new to python, and postgresql for that matter, and wondering if anyone has any samples I can look at,  I read over the Module, but im still kind of new and would really appreciate any 
samples or old code people have.  Thanks!!

Charles

[Pypgsql-users] getResult doesn't handle NULL + Patch

[Bernhard H. <bh...@in...>]

The doc-string of the connection's getResult method says that it returns
None if PQgetResult returns NULL to indicate that the query is done,
however, it raises an exception instead because it doesn't even check
the pointer it gets.

Here's a patch (relative to pgconnection.c 1.16):

*** pgconnection.c.orig	Wed Feb  6 18:42:32 2002
--- pgconnection.c	Wed Feb  6 18:43:05 2002
***************
*** 400,405 ****
--- 400,412 ----
  
      res = PQgetResult(PgConnection_Get(self));
  
+     if (!res)
+     {
+ 	/*  the query is done. Return None */
+ 	Py_INCREF(Py_None);
+ 	return Py_None;
+     }
+     
      if ((rtype = getResultType(res)) == RESULT_ERROR)
      {
  	PyObject *exc;



Bernhard


-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                               http://mapit.de/

Re: [Pypgsql-users] Asynchronous connections

[Bernhard H. <bh...@in...>]

"Billy G. Allie" <bg...@mu...> writes:

> Bernhard Herzog wrote:
> > "Billy G. Allie" <Bil...@mu...> writes:
> > 
> > > Bernhard Herzog wrote:
> > > > Is it possible to use pyPgSQL for asynchronous connections? It seems to
> > > > be the only Python/PostgreSQL module that actually wraps the relevant
> > > > libpg functions, but the Python API doesn't provide access to them. Is
> > > > anybody actually using them?
> > > 
> > > The pyPgSQL.PgSQL module does not use asynchronous connections.  If you need
> > > to use ansynchronous connections you will have to use pyPgSQL.libpq module,
> > > which exposes the appropiate API. 
> > 
> > That's what I ended up doing. I also modified the copy a bit to
> > reactivate the PQconnectStart bindings for asynchronouse connections and
> > removed the version specific stuff because that wouldn't work with
> > PQconnectStart and we won't need the compatibility code.
> 
> I've re-activated the PQconnectStart bindings in the CVS version. 

Without the other changes I made it probably doesn't work.

> Can you send me the additional things you changed. I am curious as to
> what they were. Thanks.

A problem with PQconnectStart was that PgConnection_New tried to execute
a query (to determine the version of the server) even before the
connection procedure had been finished. The query doesn't work at that
point and results in a segfault. I don't have to keep backwards
compatibility with older PostgreSQL anyway, so I removed all that
version code, both in pgconnection and pgresult.c.

It might be possible to keep the version code for blocking connections
and allow non-blocking connections without the version code by adding a
flag in PgConnection_New to make sure that the query is only executed
for blocking connections. How large objects (which seems to be the only
place where the version information is used) would be supported in
compatible way, I don't know and it doesn't look like we'll be needing
them.

I'll send you a diff with the changes.

I should mention, too, that non-blocking support in libpq seems to be
more or less broken by design, as another subscriber to this list
pointed out to me. Large queries, in this case those where the string
passed to PQsendQuery is sufficiently larger than the output buffer of
8K, won't be sent completely and you end up with an error. I'm working
on a patch for libpq to make it work.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                               http://mapit.de/

Re: [Pypgsql-users] Determining size of result set?

[Lars Kellogg-S. <la...@la...>]

 > This behavior is caused by the fact that pyPgSQL uses PostgreSQL
 > Portals (i.e. cursors) by default. [...]

Makes sense :).  Thanks for your help!

-- Lars

Re: [Pypgsql-users] Determining size of result set?

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

Lars Kellogg-Stedman wrote:
> Hello all,
> 
> I've just started using pyPgSQL, and I've run into a frustrating problem 
> -- how do I determine the size of a result set *before* calling one of 
> the fetchxxx() functions?
> 
> The rowcount attribute doesn't appear to be terribly useful.  As far as 
> I can tell, it simply tells me the number of rows returned by the 
> previous fetchxxx() call -- a value which I can also get just by calling 
> len() on the return from fetchxxx().  Before a fetch call, rowcount 
> always contains -1.
> 
> Is there any other way of getting at this information?

This behavior is caused by the fact that pyPgSQL uses PostgreSQL Portals (i.e. cursors) by default.  When portals are used, there is no way to determine the number of rows in the result until the rows are fetched, and the rowcount will be set to the number of rows fetched using the fetchxxx() call.  This was done so that individual (or groups of) rows could be processed without have to transfer all of the rows to the client at one time.  They can be retrieved from the back-end one at a time (or in small groups using fetchmany).  If you really need to know the number of rows before you process them, you have three options:

1.  Use a 'select count(*) from ...' query to get the number of rows that would be
    returned.

2.  Execute a fetchall() which will retrieve all the rows from the Postgresql portal.

3.  Disable the use of PortgreSQL portals by setting PgSQL.noPostgresCursor to 1. 
    This will cause PgSQL to simulate a cursor by eading the entire result set into
    memory and handing out the results as needed.  Note:  The results are stored in
    a PQresult object (see the libpq documentation),

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

Re: [Pypgsql-users] Asynchronous connections

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

Bernhard Herzog wrote:
> "Billy G. Allie" <Bil...@mu...> writes:
> 
> > Bernhard Herzog wrote:
> > > Is it possible to use pyPgSQL for asynchronous connections? It seems to
> > > be the only Python/PostgreSQL module that actually wraps the relevant
> > > libpg functions, but the Python API doesn't provide access to them. Is
> > > anybody actually using them?
> > 
> > The pyPgSQL.PgSQL module does not use asynchronous connections.  If you need
> > to use ansynchronous connections you will have to use pyPgSQL.libpq module,
> > which exposes the appropiate API. 
> 
> That's what I ended up doing. I also modified the copy a bit to
> reactivate the PQconnectStart bindings for asynchronouse connections and
> removed the version specific stuff because that wouldn't work with
> PQconnectStart and we won't need the compatibility code.

I've re-activated the PQconnectStart bindings in the CVS version.  Can you 
send me the additional things you changed.  I am curious as to what they were. 
 Thanks.

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