Menu
▾
▴
pypgsql-devel — List for discussion of pyPgSQL development.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(4) |
Aug
(9) |
Sep
(22) |
Oct
(21) |
Nov
(20) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(5) |
Mar
(30) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(13) |
Nov
(7) |
Dec
(11) |
| 2004 |
Jan
(5) |
Feb
(6) |
Mar
(6) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(10) |
Aug
(17) |
Sep
(6) |
Oct
(10) |
Nov
(3) |
Dec
|
| 2005 |
Jan
(1) |
Feb
(29) |
Mar
(6) |
Apr
(5) |
May
(5) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(27) |
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(7) |
| 2008 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2004-07-09 03:55:09
|
Patches item #987719, was opened at 2004-07-08 23:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=987719&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: Access to SQLSTATE + memory leak Initial Comment: It would be nice if one had access to the postgresql 5 character "SQLSTATE" error code, to, for example, unambiguously determine if a serialization error happened and the transaction should be re-run. The error code is more precise and future-proof than a substring check on the textual error message. I've attached a patch to the 2.4 version of pgconnection.c. It changes the value of a libpq.OperationalError exception to a tuple: (sqlstate, message), a la OSError. This fix is sufficient, but I lack the pythonic karma to say if it's the best way. I added a missing PQclear() call too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=987719&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 01:04:42
|
Bugs item #967375, was opened at 2004-06-06 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete utf-8 support Initial Comment: Hi. Again from the debian BTS (#232217). - Ben. I just found this: /usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py in execute(self=<pyPgSQL.PgSQL.Cursor instance>, query='INSERT INTO sessiondata (session,object,key,valu...UES (%(param1)s,%(param2)s,%(param3)s,%(param4)s)', *parms={'param1': "'00E003088E7A'", 'param2': "'userinfo'", 'param3': "'surname'", 'param4': "'Hj\xf0\xae\xae\xa5v\xe5\xa7\xa2 type='"}) 3070 self.conn.__dict__["inTransaction"] = 0 3071 self.conn._Connection__closeCursors() 3072 raise OperationalError, msg 3073 except InternalError, msg: 3074 # An internal error occured. Try to get to a sane state. global OperationalError = <class libpq.OperationalError> msg = <libpq.OperationalError instance> OperationalError: ERROR: Unicode >= 0x10000 is not supported which seems to say that PgSQL only supports a subset of the unicode character set. This is a bit of a problem for us since we have customers using those (which is how I got that backtrace). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 01:00:09
|
Bugs item #967372, was opened at 2004-06-06 11:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967372&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: PgNumeric.__cmp__ does not handle non-numbers Initial Comment: Hi. I received the following report through the debian BTS (#251401). The fix is very simple (I've already applied it to the debian packages) -- simply change "return None" to "return 1" in the __cmp__ implementation. The original bug report is below, and the one-line patch is attached. Ben. ORIGINAL BUG REPORT: I just had a website break due to what eventually turned out to be a bug in the __cmp__ method for PgNumeric. The problem is a small bug in its return values: when it can not coerce the object it is compared to to a PgNumeric it returns None, which is not allowed for a __cmp__ function. Simply fixing the return value fixes this, see the patch below. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967372&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-05-13 11:28:00
|
Bugs item #882032, was opened at 2004-01-22 11:22 Message generated for change (Comment added) made by runefro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Billy G. Allie (ballie01) Summary: Wrong PG_Version check for dbExperts PostgreSQL Initial Comment: We have dbExperts PostgreSQL (a native Postgres for Windows). The dbExperts people add a -dbexperts to the VersionString (after the Version number). This makes pgversion.c upset. We are using pypgsql version 2.4 Attached is a patch to fix this issue. ---------------------------------------------------------------------- Comment By: Rune Frøysa (runefro) Date: 2004-05-13 13:27 Message: Logged In: YES user_id=604567 This problem also affects rh-postgresql-server-7.3.6-1 from redhat. With the patch, the only error from test/PgSQLTestCases.py is: FAIL: CheckPgVer (__main__.PgSQLTestCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/PgSQLTestCases.py", line 591, in CheckPgVer self.fail(msg) File "/usr/lib/python2.2/unittest.py", line 254, in fail raise self.failureException, msg AssertionError: SELECT version() says 7.3.6-RH, cnx.version says 7.3.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-05-10 03:38:32
|
Patches item #931857, was opened at 2004-04-08 13:15 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=931857&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Tim Middleton (ragica) >Assigned to: Billy G. Allie (ballie01) Summary: Add "debug" output hook in execute() Initial Comment: I have to use pygresql a lot. This patch provides something like one of the few things I miss from it when using pyPgSQL. The unified diff is against version 2.4. The changes are, of course, transparent. Perhaps there's a better way/place to do this, but this works for me. Perhaps others would find it handy. It adds a "debug" attribute to the connection object, which is then used by the Cursor.execute() method. Connection.debug may be set to provide a way of seeing processed SQL queries immediately before they are executed. If Connection.debug is set to a function, or other callable object, the the call will be made with the query string as the argument. If Connection.debug is set to a non-empty string that string will have the query string substituted into it (using the %s code). If Connection.debug is set to 'TEXT' the query string will be printed with added new-line and seperating rows surrounding it. If Connection.debug is set to HTML or PRE then the query string will be escaped and output within an HTML "div" or "pre" block. The block will have a light grey background, and a thin dashed border. This is useful for CGI debugging. If Connection.debug is set to an empty string the query string will simply be printed. If Connection.debug is set to None (the default value) or a non-callable non-string type it will be ignored. Setting Connection.debug affects all cursors created by that connection. You can of course set the Connection.debug from a Cursor object like this: Cursor.conn.debug = ''. Examples:: from pyPgSQL import PgSQL # set the debug to the predefined TEXT output dbconn = PgSQL('db') dbconn.debug = "TEXT" # or setting from a Cursor object dbcurs = conn.Cursor() dbcurs.conn.debug = "Query Sent:\n%s\n" ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-05-09 23:38 Message: Logged In: YES user_id=8500 I have added the debug feature describe to the libpq.PgConnection object and made it accessable from the PgSQL.Connection object. It made more sense to me for it to be implemented in the lower level libpq module. The changes have been commited to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=931857&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-05-08 21:15:11
|
Patches item #942623, was opened at 2004-04-26 16:43 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=942623&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Wesley J. Chun (wesc) Assigned to: Nobody/Anonymous (nobody) Summary: upgrade test/PgSQLTestCases.py to PG7.4 Initial Comment: % diff -C3 test/PgSQLTestCases.py *** test/PgSQLTestCases.py Sat Nov 30 20:59:25 2002 --- test/PgSQLTestCases74.py Mon Apr 26 13:17:48 2004 *************** *** 615,621 **** def CheckExecuteWithSingleton(self): """Test execute() with a singleton string as the parameter.""" ! if self.vstr.startswith("7.3"): flen = 11 elif self.vstr.startswith("7.2"): flen = 9 --- 615,623 ---- def CheckExecuteWithSingleton(self): """Test execute() with a singleton string as the parameter.""" ! if self.vstr.startswith("7.4"): ! flen = 11 ! elif self.vstr.startswith("7.3"): flen = 11 elif self.vstr.startswith("7.2"): flen = 9 *************** *** 798,804 **** # Define the row counts for various version of PosrtgreSQL # Note: We only have to check for the minor version number in order # to determine the needed row counts. ! rc = { '7.3':124, '7.2':101, '7.1':80, '7.0':65, '6.5':47 } v = self.vstr --- 800,806 ---- # Define the row counts for various version of PosrtgreSQL # Note: We only have to check for the minor version number in order # to determine the needed row counts. ! rc = { '7.4':137, '7.3':124, '7.2':101, '7.1':80, '7.0':65, '6.5':47 } v = self.vstr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=942623&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-05-08 20:50:46
|
Bugs item #882032, was opened at 2004-01-22 05:22 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Howitz (icemac) >Assigned to: Billy G. Allie (ballie01) Summary: Wrong PG_Version check for dbExperts PostgreSQL Initial Comment: We have dbExperts PostgreSQL (a native Postgres for Windows). The dbExperts people add a -dbexperts to the VersionString (after the Version number). This makes pgversion.c upset. We are using pypgsql version 2.4 Attached is a patch to fix this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-04-26 20:44:00
|
Patches item #942623, was opened at 2004-04-26 13:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=942623&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wesley J. Chun (wesc) Assigned to: Nobody/Anonymous (nobody) Summary: upgrade test/PgSQLTestCases.py to PG7.4 Initial Comment: % diff -C3 test/PgSQLTestCases.py *** test/PgSQLTestCases.py Sat Nov 30 20:59:25 2002 --- test/PgSQLTestCases74.py Mon Apr 26 13:17:48 2004 *************** *** 615,621 **** def CheckExecuteWithSingleton(self): """Test execute() with a singleton string as the parameter.""" ! if self.vstr.startswith("7.3"): flen = 11 elif self.vstr.startswith("7.2"): flen = 9 --- 615,623 ---- def CheckExecuteWithSingleton(self): """Test execute() with a singleton string as the parameter.""" ! if self.vstr.startswith("7.4"): ! flen = 11 ! elif self.vstr.startswith("7.3"): flen = 11 elif self.vstr.startswith("7.2"): flen = 9 *************** *** 798,804 **** # Define the row counts for various version of PosrtgreSQL # Note: We only have to check for the minor version number in order # to determine the needed row counts. ! rc = { '7.3':124, '7.2':101, '7.1':80, '7.0':65, '6.5':47 } v = self.vstr --- 800,806 ---- # Define the row counts for various version of PosrtgreSQL # Note: We only have to check for the minor version number in order # to determine the needed row counts. ! rc = { '7.4':137, '7.3':124, '7.2':101, '7.1':80, '7.0':65, '6.5':47 } v = self.vstr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=942623&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-04-08 17:15:53
|
Patches item #931857, was opened at 2004-04-08 13:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=931857&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Middleton (ragica) Assigned to: Nobody/Anonymous (nobody) Summary: Add "debug" output hook in execute() Initial Comment: I have to use pygresql a lot. This patch provides something like one of the few things I miss from it when using pyPgSQL. The unified diff is against version 2.4. The changes are, of course, transparent. Perhaps there's a better way/place to do this, but this works for me. Perhaps others would find it handy. It adds a "debug" attribute to the connection object, which is then used by the Cursor.execute() method. Connection.debug may be set to provide a way of seeing processed SQL queries immediately before they are executed. If Connection.debug is set to a function, or other callable object, the the call will be made with the query string as the argument. If Connection.debug is set to a non-empty string that string will have the query string substituted into it (using the %s code). If Connection.debug is set to 'TEXT' the query string will be printed with added new-line and seperating rows surrounding it. If Connection.debug is set to HTML or PRE then the query string will be escaped and output within an HTML "div" or "pre" block. The block will have a light grey background, and a thin dashed border. This is useful for CGI debugging. If Connection.debug is set to an empty string the query string will simply be printed. If Connection.debug is set to None (the default value) or a non-callable non-string type it will be ignored. Setting Connection.debug affects all cursors created by that connection. You can of course set the Connection.debug from a Cursor object like this: Cursor.conn.debug = ''. Examples:: from pyPgSQL import PgSQL # set the debug to the predefined TEXT output dbconn = PgSQL('db') dbconn.debug = "TEXT" # or setting from a Cursor object dbcurs = conn.Cursor() dbcurs.conn.debug = "Query Sent:\n%s\n" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=931857&group_id=16528 |
|
From: Mike C. F. <mcf...@ro...> - 2004-03-20 10:46:26
|
The name of the file:
pyPgSQL-2.4.win32-py2.1.exe
implies that the targeted Python version is 2.1 (py2.1), not Python 2.3.
You can only use binary versions of extensions such as pyPgSQL with the
version of Python for which they were compiled. IOW, download the
version for the Python you want to use, particularly:
pyPgSQL-2.4.win32-py2.3.exe
HTH,
Mike
Frans Gunawan wrote:
> I'm sorry, I have some questions about pyPgSQL-2.4.win32-py2.1.exe
> installation process.
> I have instaled Python2.3 and mxDateTime module, PostgreSQL 7.3 (using
> Cygwin) but when I try to install pyPgSQL using
> pyPgSQL-2.4.win32-py2.1.exe, the process stop in form :
> select Phyton installation to use, and I can't enter installation
> directory.
> Is there something wrong with my system setup?
...
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: Frans G. <fra...@ya...> - 2004-03-16 03:57:13
|
I'm sorry, I have some questions about pyPgSQL-2.4.win32-py2.1.exe installation process. I have instaled Python2.3 and mxDateTime module, PostgreSQL 7.3 (using Cygwin) but when I try to install pyPgSQL using pyPgSQL-2.4.win32-py2.1.exe, the process stop in form : select Phyton installation to use, and I can't enter installation directory. Is there something wrong with my system setup? Thank You Frans Gunawan Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam |
|
From: SourceForge.net <no...@so...> - 2004-03-11 08:10:16
|
Patches item #852606, was opened at 2003-12-02 08:40 Message generated for change (Comment added) made by shauncutts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick Wagstrom (pridkett) Assigned to: Billy G. Allie (ballie01) Summary: Fix for Fedora linux with patched PostgreSQL pacakages Initial Comment: Fedora Linux Core 1 has a patched version of PostgreSQL that reports it's version as 7.3.4-RH which causes the version checking procedure to die and report that we're not connecting to a valid database. This fixes that and makes it so versions that end in "-RH" are recognized as valid versions, allowing pyPgSQL to work under Fedora Core 1 (and I'd imagine anyplace else with the RedHat database). ---------------------------------------------------------------------- Comment By: Shaun Cutts (shauncutts) Date: 2004-03-11 02:59 Message: Logged In: YES user_id=232124 The following is an alternative solution. Either is needed for RedHat ES as well as Fedora. The submitted version seems to trim out "-RH" wherever it occurs. This variation is to allow -<anything> after the patch # in the version string. A "real" fix for this would be to have newer postgres support version_major() etc functions rather than having to parse strings whose definitions aren't guarenteed. diff pgversion.c-v1.21 pgversion.c 293c293 < token = pg_strtok_r((char *)NULL, ".", &save_ptr); --- > token = pg_strtok_r((char *)NULL, ".-", &save_ptr); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-03-09 10:21:10
|
Bugs item #656798, was opened at 2002-12-20 14:08 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Peter Maas (petermaas) Assigned to: Gerhard Häring (ghaering) Summary: ZpyPgSQLDA failure in ZOPE 2.6 / Win2k Initial Comment: I try to access postgresql 7.1 db on linux server with ZpyPgSQLDA. running on Zope 2.6.0 (python 2.1.3) on Win2000. On database1 (which I don't own) a SELECT on a 665 rows table yields the ZOPE error: Error Type: RuntimeError Error Value: maximum recursion depth exceeded A SELECT on a 22 rows table yields: This statement returned no results. On another database (which I own) on the same server I get the desired result (10 row table) but it takes quite long (about 5 seconds). I tried all cases in Python 2.1.3 (and Python 2.2) directly with pyPgSQL and everything worked well (got the results nearly immediately). So I suspect that there's something wrong with Zope or ZpyPgSQLDA. Regards, Peter. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2003-02-17 14:13 Message: Logged In: YES user_id=163326 Sorry, I haven't looked into ZpyPgSQLDA for ages. Probably because I currently don't use ZOPE myself. Considering this, I'd suggest you check out ZpsycopgDA instead, as it's likely better supported at this time. There seem to be win32 binaries available at http://www.zope.org/Members/pvl/PsycopgWin32/psycopgWin32/view I hate to have to recommend the "competition", but looked at raitionally, this is most likely the best solution for now. Sorry for the inconvenience. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-03-09 05:45:58
|
Patches item #852606, was opened at 2003-12-02 08:40 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Patrick Wagstrom (pridkett) >Assigned to: Billy G. Allie (ballie01) Summary: Fix for Fedora linux with patched PostgreSQL pacakages Initial Comment: Fedora Linux Core 1 has a patched version of PostgreSQL that reports it's version as 7.3.4-RH which causes the version checking procedure to die and report that we're not connecting to a valid database. This fixes that and makes it so versions that end in "-RH" are recognized as valid versions, allowing pyPgSQL to work under Fedora Core 1 (and I'd imagine anyplace else with the RedHat database). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-03-09 05:44:39
|
Bugs item #896600, was opened at 2004-02-13 11:23 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=896600&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Dick Kniep (dickkniep) >Assigned to: Billy G. Allie (ballie01) Summary: Simple calling error Initial Comment: Enclosed an error listing which looks very easy to fix File "/home/dick/Clienten/src/Hoofdframe.py", line 297, in self.FactuurProductlist.BldList(clear=Opendb.TableObjs.RebuildFactList) File "/home/dick/Clienten/src/DefColumns.py", line 479, in BldList self.ShowScrn = self.VulScherm() File "/home/dick/Clienten/src/DefColumns.py", line 528, in VulScherm self.Vulrij(rec, self.n) File "/home/dick/Clienten/src/DefColumns.py", line 576, in Vulrij self.VulSchermKolommen(rec, teller) File "/home/dick/Clienten/src/DefColumns.py", line 658, in VulSchermKolommen strfld = self.GetField(kolom, fetchroutine, h, rec) File "/home/dick/Clienten/src/DefColumns.py", line 676, in GetField strfld = fetchroutine(rec, kolom) File "/home/dick/Clienten/src/Hoofdframe.py", line 65, in <lambda> ("regelprijs", lambda rec, veld: self.getRegelPrijs(rec),"Regelprijs")) File "/home/dick/Clienten/src/Hoofdframe.py", line 127, in getRegelPrijs return str(rec.contractprijs * rec.aantal) File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 1598, in __rmul__ return self.__mul__(self, other) TypeError: __mul__() takes exactly 2 arguments (3 given) Obviously this should be: return self.__mul__(other) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=896600&group_id=16528 |
|
From: Mike C. F. <mcf...@ro...> - 2004-02-25 11:02:38
|
There's a minor bug in __closeCursors, basically there's an assumption
made that the weakrefs will all resolve to cursor instances, when they
can just as easily return a None:
if noWeakRef:
curs = self.cursors[:]
else:
curs = filter( None, map(lambda x: x(),
self.cursors.data.values()))
without this you'll see this every once in a while:
Exception exceptions.AttributeError: "'NoneType' object has no
attribute 'close'" in <bound method Connection.__del__ of
<pyPgSQL.PgSQL.Connection instance at 0x0131A648>> ignored
Enjoy all,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: Mike C. F. <mcf...@ro...> - 2004-02-25 10:54:12
|
Found it. At some point I must have accidentally hit a delete key and
out-dented a line in PgSQL.py while trying to track down a different error:
if len(parms) == 1 and \
(type(parms[0]) in [DictType, ListType, TupleType] or \
isinstance(parms[0], PgResultSet)):
parms = _quoteall(self.__unicodeConvert(parms[0]))
self.res = self.conn.conn.query(_qstr % parms)
else:
parms = self.__unicodeConvert(parms)
parms = tuple(map(_quote,
self.__unicodeConvert(parms)));
self.res = self.conn.conn.query(_qstr % parms)
so the query wound up being executed twice if a request met a particular
requirement, and once otherwise. The reason I couldn't reproduce the
error in a script is that I was passing in the fully-expanded SQL
queries in order to be sure I was executing exactly what was getting to
the engine. Those would always take the "else" branch and thus only
create the cursor once (and, incidentally, this explains the
previously-seen problem of mysterious duplicate inserts which triggered
the whole update to PostgreSQL 7.4 in the first place).
Sigh. Two days gone for a stupid reformatting/random keypress error. I
should beat myself about the head for that one. Sorry for bothering
everyone with this. Night all,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: Mike C. F. <mcf...@ro...> - 2004-02-25 10:02:42
|
More details here. The error is occurring on the first call to
cursor.execute in the process (and all subsequent calls), so not likely
a matter of leftover cursors or cursors hanging around from previous
calls within the process. First query is:
DECLARE "PgSQL_01323DF01" CURSOR FOR SELECT tablename FROM pg_tables
WHERE tablename !~ '^pg_' AND tablename !~ '^pga_';
setting noPostgresCursor true works around the effect (i.e. the queries
work fine). (Note: the passed in query starts with "SELECT", the cursor
class is adding the declare when noPostgresCursor is false).
As to why I can't provoke the darned thing to show the same error with a
script executing the same query, no clue. I'm assuming it's some weird
effect of, for instance, not having a hard reference to a connection
anywhere (though that fails in a different way in my tests), or some
weird interaction with the apps logging DB connection (though that's not
getting called in the test, and simulating it's existence with another
connection doesn't affect anything), or bad karma left over from some
previous life :) .
For now I'll just set noPostgresCursor true and get back to real work,
but I would still be very curious to see what others think might cause
such an effect.
Have fun,
Mike
Mike C. Fletcher wrote:
...
> Traceback (most recent call last):
> File "p:\sharedinstall\pyPgSQL\PgSQL.py", line 3098, in execute
> self.res = self.conn.conn.query(_qstr % parms)
> OperationalError: ERROR: cursor "PgSQL_013CAD78" already exists
...
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: Mike C. F. <mcf...@ro...> - 2004-02-25 07:27:18
|
I've just recently upgraded to postgresql 7.4 on cygwin, and am now
seeing some strange behaviour of PyPgSQL cursors. There were a number
of changes to the semantics of cursor lifetimes in the 7.3 to 7.4
transition, so I'm wondering if they might be the source of the
problems, and if so, if anyone has worked around them already.
Basically the symptoms are that in a large application, I'm getting
operational errors raised like that below (I've been unable to duplicate
the effect in small test-scripts, unfortunately). The errors are
consistently seen with certain tests. The code in question is using a
single connection, creating temporary cursors for individual
(sequentially occurring) operations. There's no threading going on.
This is with the latest PyPgSQL:
(self.conn.conn is: <Opened PgConnection at 013D19E0>)
Traceback (most recent call last):
File "p:\sharedinstall\pyPgSQL\PgSQL.py", line 3098, in execute
self.res = self.conn.conn.query(_qstr % parms)
OperationalError: ERROR: cursor "PgSQL_013CAD78" already exists
I've been playing with adding a serial number to the name of the cursor,
and it does appear as though the same cursor object is attempting to
multiply-create itself during the query call (as opposed to a chance
duplication of memory address causing two temporally disjoint cursors to
share the same name).
I'm thinking I'll have to regress to PostgreSQL 7.3 for now, but would
love to hear if anyone has encountered and/or worked around the issue.
Thoughts appreciated,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: Mike C. F. <mcf...@ro...> - 2004-02-24 12:19:01
|
I just upgraded a database to PostgreSQL 7.4 and am now encountering a
weird set of errors:
OperationalError: (SQLQuery) ERROR: cursor "PgSQL_01AA9B48" already
exists
I'm assuming the cursor name is being auto-generated from somewhere.
I'm also assuming that the problem is something like my not explicitly
closing cursors (I never close any cursors, always trusting that the
system will de-allocate them). The same code was working fine with
PostgreSQL 7.3, so I can only imagine that its a change in the semantics
of 7.3 vs 7.4 cursors. Another possibility I could imagine would be
something like the names being based on Python object ids, and a re-used
object id causing a name collision. That seems a little stretched,
though. Alternately, could be that PyPgSQL is declaring "HOLD" on all
cursors?
I see the following in the 7.4 changelog:
Cursors conform more closely to the SQL standard
The commands "FETCH" and "MOVE" have been overhauled to conform
more closely to the SQL standard.
Cursors can exist outside transactions
These cursors are also called holdable cursors.
* Allow cursors outside transactions using WITH HOLD (Neil)
In previous releases, cursors were removed at the end of the
transaction that created them. Cursors can now be created with the
WITH HOLD option, which allows them to continue to be accessed
after the creating transaction has committed.
My question then is: has anyone successfully used PyPgSQL with
PostgreSQL 7.4 for more than trivial operations, and if so, did you
encounter the above behaviour, and if so, what did you do to eliminate it?
I'll have to look into this more deeply tomorrow (I'm dead at the
moment), so any hints would be helpful.
Have fun all,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: SourceForge.net <no...@so...> - 2004-02-13 16:26:18
|
Bugs item #896600, was opened at 2004-02-13 17:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=896600&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dick Kniep (dickkniep) Assigned to: Nobody/Anonymous (nobody) Summary: Simple calling error Initial Comment: Enclosed an error listing which looks very easy to fix File "/home/dick/Clienten/src/Hoofdframe.py", line 297, in self.FactuurProductlist.BldList(clear=Opendb.TableObjs.RebuildFactList) File "/home/dick/Clienten/src/DefColumns.py", line 479, in BldList self.ShowScrn = self.VulScherm() File "/home/dick/Clienten/src/DefColumns.py", line 528, in VulScherm self.Vulrij(rec, self.n) File "/home/dick/Clienten/src/DefColumns.py", line 576, in Vulrij self.VulSchermKolommen(rec, teller) File "/home/dick/Clienten/src/DefColumns.py", line 658, in VulSchermKolommen strfld = self.GetField(kolom, fetchroutine, h, rec) File "/home/dick/Clienten/src/DefColumns.py", line 676, in GetField strfld = fetchroutine(rec, kolom) File "/home/dick/Clienten/src/Hoofdframe.py", line 65, in <lambda> ("regelprijs", lambda rec, veld: self.getRegelPrijs(rec),"Regelprijs")) File "/home/dick/Clienten/src/Hoofdframe.py", line 127, in getRegelPrijs return str(rec.contractprijs * rec.aantal) File "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 1598, in __rmul__ return self.__mul__(self, other) TypeError: __mul__() takes exactly 2 arguments (3 given) Obviously this should be: return self.__mul__(other) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=896600&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-01-22 10:22:00
|
Bugs item #882032, was opened at 2004-01-22 11:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong PG_Version check for dbExperts PostgreSQL Initial Comment: We have dbExperts PostgreSQL (a native Postgres for Windows). The dbExperts people add a -dbexperts to the VersionString (after the Version number). This makes pgversion.c upset. We are using pypgsql version 2.4 Attached is a patch to fix this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 |
|
From: Mike C. F. <mcf...@ro...> - 2004-01-22 06:26:17
|
There's a bug in the __closeCursors function, line 2437 in PgSQL.py.
The code is dereferencing a weakref, which, if the object has been gc'd
returns None, but the code doesn't check to see that the returned value
is not None. I've just encountered a situation where a None in present
in the stream, so at least in some situations it can occur :) .
def __closeCursors(self, flag=0):
"""
__closeCursors() - closes all cursors associated with this
connection"""
if self.__anyLeft():
if noWeakRef:
curs = self.cursors[:]
else:
curs = map(lambda x: x(), self.cursors.data.values())
for i in curs:
if flag:
i.close()
else:
i._Cursor__reset()
return self.inTransaction
the if weakRef clause should read:
curs = filter( None, map(lambda x: x(),
self.cursors.data.values()))
or, if we want to use list comprehensions:
curs = [y for y in [ x() for x in
self.cursors.data.values() ] if y ]
or we can just do:
for i in curs:
if i:
...
Enjoy,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
|
From: SourceForge.net <no...@so...> - 2004-01-19 02:37:21
|
Bugs item #863925, was opened at 2003-12-21 08:39 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=863925&group_id=16528 >Category: PgSQL Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Ben Burton (bab) >Assigned to: Billy G. Allie (ballie01) Summary: FutureWarning (negative integers and signed strings) Initial Comment: Hi. The following issue was reported in the Debian BTS (#224325): I have a python script which started to output this warning: /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 The following patch should fix it: --- python-pgsql-2.4.0.old/pyPgSQL/PgSQL.py 2003-12-22 00:17:47.000000000 +1100 +++ python-pgsql-2.4.0/pyPgSQL/PgSQL.py 2003-12-22 00:19:36.000000000 +1100 @@ -2641,7 +2641,7 @@ if name is None: if isRefCursor: raise TypeError, "Reference cursor requires a name." - name = "PgSQL_%08X" % id(self) + name = "PgSQL_%08X" % long(id(self)) elif type(name) is not StringType: raise TypeError, "Cursor name must be a string." Thanks - Ben. :) ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-01-18 21:37 Message: Logged In: YES user_id=8500 Thanks for the report and patch. I will apply this to the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=863925&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-01-19 02:31:15
|
Bugs item #879531, was opened at 2004-01-18 18:54 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=879531&group_id=16528 >Category: PgSQL Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Ben Burton (bab) >Assigned to: Billy G. Allie (ballie01) Summary: Does not handle select into properly Initial Comment: (Received through the Debian BTS as #226946) There is a bug in the execute method when dealing with select into queries: it checks using a simple regexp if a select statement is about to be executed and if so it will declare a cursor. This does not work for select into queries, which do not support cursors. Unfortunately the current approach of using a regexp to check for exceptions does not work very well since it is not possible to reliable check for select into statements without parsing the statement. Thanks - Ben. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-01-18 21:31 Message: Logged In: YES user_id=8500 The work around for the problem is to turn off the use of PostgreSQL portals. I will modify the code so that portals are not used both select and into are used in the same query. Yes, i know that there can be false positives (ie into is used in a string in the query), but at worse, a portal will not be used in this instance. For the application point of view, there is no difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=879531&group_id=16528 |
1 message has been excluded from this view by a project administrator.
