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: <no...@so...> - 2002-10-20 17:22:15
|
Support Requests item #615598, was opened at 2002-09-27 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=615598&group_id=16528 Category: PgSQL.py Group: None >Status: Closed Priority: 5 Submitted By: Wild Bill (wildbilly) Assigned to: Nobody/Anonymous (nobody) Summary: Unintuitive error messages Initial Comment: Hello, My python code looks like this: cursor.execute("""INSERT INTO table1 VALUES(%s, %s, %s, %s, %s, %s, %s)""", (iurl, tags2, val2, depth, val3, val4, val5)) And the error message looks like this: libpq.OperationalError ERROR: parser: parse error at or near "l" Which means absolutely nothing to me. I try some debugging code to see what the SQL looks like: print """INSERT INTO able1 VALUES(%s, %s, %s, %s, %s, %s, %s);""" % (iurl, tags2, val2, depth, val3, val4, val5) Which outputs INSERT INTO table1 VALUES(http://www.dmoz.org/Society/, 0, 3, 500, 50000, 200209271030, 0); Any thoughts? Does PgSQL module take care of backslashing, adding appropriate apostraphes, etc? I can't find any documentation on this anywhere. Thanks ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-20 19:22 Message: Logged In: YES user_id=163326 I suppose this is now solved. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:54 Message: Logged In: YES user_id=163326 Using the % operator yourself doesn't help for debugging. Please activate SQL logging by accessing the toggleShowQuery attribute on the low-level connection attribute, something like this: from pyPgSQL import PgSQL con = PgSQL.connect(...) con.con.toggleShowQuery cursor = con.cursor() cursor.execute(...) Could you please post the SQL that gets sent to the backend? Btw. the libpq.OperationalError comes from the PostgreSQL backend. We can't do much about improving it. It just means PostgreSQL cannot parse the SQL statement it gets sent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=615598&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 14:41:25
|
Bugs item #625121, was opened at 2002-10-18 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alexander Meisel (alex) Assigned to: Billy G. Allie (ballie01) >Summary: Error in cursor.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 16:41 Message: Logged In: YES user_id=163326 Fixed in revision 1.25 of libpqmodule.c. Alex, we'll likely release a beta version of pyPgSQL 2.3 this weekend, and I'd be glad if you could check if it'll work for you. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 15:49 Message: Logged In: YES user_id=163326 Ok, got it. In: pgboolean.c:libPQbool_FromInt ParseTuple needs an "l" format character to parse into a long, instead of a "i". I'll check all the other format strings, too, then check the change in. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:48 Message: Logged In: YES user_id=163326 Ok, I'll see what I can find out about the Alpha ..... Damn, the SF folks did install a PostgreSQL that you can't start, but without the header files :-( So we're back to compiling PostgreSQL ourselves there. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:42 Message: Logged In: YES user_id=163326 Billy, you do have access to an Alpha box :-) A Debian 3.0/Alpha box that you can access by logging in with ssh at cf.sf.net (or compilefarm.sourceforge.net). This way, you also have access to Sun Solaris, Mac OS X/Server and a few other boxes. This box even has Pyhton 2.1.3 and PostgreSQL installed. The only problem is how to access the db server on this machine :-( If nothing else helps, I believe PostgreSQL can be started under a normal user account (with a different pg_hba.conf, data directory and port, right?) ---------------------------------------------------------------------- Comment By: Alexander Meisel (alex) Date: 2002-10-19 12:35 Message: Logged In: YES user_id=617 Hmm .... I sorry, I didn't find the FAQ in the first place. But with regards to the Boolean constructor I can arrange a login for you on the box (Will send you the details via E-Mail). Thx Alex ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-19 02:08 Message: Logged In: YES user_id=8500 In regards to the rowcount problem, it is not a problem. Please see our FAQ at http://pypgsql.sourceforge.net/pypgsql-faq.html#id2781273 I will look into the testcase to see if I can figure out the problem with the Boolean constructor. Be warned that I do not have access to an alpha box, so I may not find out anything :-( Bill Allie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 13:49:59
|
Bugs item #625121, was opened at 2002-10-18 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Meisel (alex) Assigned to: Billy G. Allie (ballie01) Summary: Error in corsur.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 15:49 Message: Logged In: YES user_id=163326 Ok, got it. In: pgboolean.c:libPQbool_FromInt ParseTuple needs an "l" format character to parse into a long, instead of a "i". I'll check all the other format strings, too, then check the change in. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:48 Message: Logged In: YES user_id=163326 Ok, I'll see what I can find out about the Alpha ..... Damn, the SF folks did install a PostgreSQL that you can't start, but without the header files :-( So we're back to compiling PostgreSQL ourselves there. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:42 Message: Logged In: YES user_id=163326 Billy, you do have access to an Alpha box :-) A Debian 3.0/Alpha box that you can access by logging in with ssh at cf.sf.net (or compilefarm.sourceforge.net). This way, you also have access to Sun Solaris, Mac OS X/Server and a few other boxes. This box even has Pyhton 2.1.3 and PostgreSQL installed. The only problem is how to access the db server on this machine :-( If nothing else helps, I believe PostgreSQL can be started under a normal user account (with a different pg_hba.conf, data directory and port, right?) ---------------------------------------------------------------------- Comment By: Alexander Meisel (alex) Date: 2002-10-19 12:35 Message: Logged In: YES user_id=617 Hmm .... I sorry, I didn't find the FAQ in the first place. But with regards to the Boolean constructor I can arrange a login for you on the box (Will send you the details via E-Mail). Thx Alex ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-19 02:08 Message: Logged In: YES user_id=8500 In regards to the rowcount problem, it is not a problem. Please see our FAQ at http://pypgsql.sourceforge.net/pypgsql-faq.html#id2781273 I will look into the testcase to see if I can figure out the problem with the Boolean constructor. Be warned that I do not have access to an alpha box, so I may not find out anything :-( Bill Allie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 12:48:53
|
Bugs item #625121, was opened at 2002-10-18 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Meisel (alex) Assigned to: Billy G. Allie (ballie01) Summary: Error in corsur.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:48 Message: Logged In: YES user_id=163326 Ok, I'll see what I can find out about the Alpha ..... Damn, the SF folks did install a PostgreSQL that you can't start, but without the header files :-( So we're back to compiling PostgreSQL ourselves there. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:42 Message: Logged In: YES user_id=163326 Billy, you do have access to an Alpha box :-) A Debian 3.0/Alpha box that you can access by logging in with ssh at cf.sf.net (or compilefarm.sourceforge.net). This way, you also have access to Sun Solaris, Mac OS X/Server and a few other boxes. This box even has Pyhton 2.1.3 and PostgreSQL installed. The only problem is how to access the db server on this machine :-( If nothing else helps, I believe PostgreSQL can be started under a normal user account (with a different pg_hba.conf, data directory and port, right?) ---------------------------------------------------------------------- Comment By: Alexander Meisel (alex) Date: 2002-10-19 12:35 Message: Logged In: YES user_id=617 Hmm .... I sorry, I didn't find the FAQ in the first place. But with regards to the Boolean constructor I can arrange a login for you on the box (Will send you the details via E-Mail). Thx Alex ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-19 02:08 Message: Logged In: YES user_id=8500 In regards to the rowcount problem, it is not a problem. Please see our FAQ at http://pypgsql.sourceforge.net/pypgsql-faq.html#id2781273 I will look into the testcase to see if I can figure out the problem with the Boolean constructor. Be warned that I do not have access to an alpha box, so I may not find out anything :-( Bill Allie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 12:42:26
|
Bugs item #625121, was opened at 2002-10-18 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Meisel (alex) Assigned to: Billy G. Allie (ballie01) Summary: Error in corsur.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-19 14:42 Message: Logged In: YES user_id=163326 Billy, you do have access to an Alpha box :-) A Debian 3.0/Alpha box that you can access by logging in with ssh at cf.sf.net (or compilefarm.sourceforge.net). This way, you also have access to Sun Solaris, Mac OS X/Server and a few other boxes. This box even has Pyhton 2.1.3 and PostgreSQL installed. The only problem is how to access the db server on this machine :-( If nothing else helps, I believe PostgreSQL can be started under a normal user account (with a different pg_hba.conf, data directory and port, right?) ---------------------------------------------------------------------- Comment By: Alexander Meisel (alex) Date: 2002-10-19 12:35 Message: Logged In: YES user_id=617 Hmm .... I sorry, I didn't find the FAQ in the first place. But with regards to the Boolean constructor I can arrange a login for you on the box (Will send you the details via E-Mail). Thx Alex ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-19 02:08 Message: Logged In: YES user_id=8500 In regards to the rowcount problem, it is not a problem. Please see our FAQ at http://pypgsql.sourceforge.net/pypgsql-faq.html#id2781273 I will look into the testcase to see if I can figure out the problem with the Boolean constructor. Be warned that I do not have access to an alpha box, so I may not find out anything :-( Bill Allie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 10:35:30
|
Bugs item #625121, was opened at 2002-10-18 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Meisel (alex) Assigned to: Billy G. Allie (ballie01) Summary: Error in corsur.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- >Comment By: Alexander Meisel (alex) Date: 2002-10-19 10:35 Message: Logged In: YES user_id=617 Hmm .... I sorry, I didn't find the FAQ in the first place. But with regards to the Boolean constructor I can arrange a login for you on the box (Will send you the details via E-Mail). Thx Alex ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-19 00:08 Message: Logged In: YES user_id=8500 In regards to the rowcount problem, it is not a problem. Please see our FAQ at http://pypgsql.sourceforge.net/pypgsql-faq.html#id2781273 I will look into the testcase to see if I can figure out the problem with the Boolean constructor. Be warned that I do not have access to an alpha box, so I may not find out anything :-( Bill Allie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 00:22:04
|
Bugs item #611979, was opened at 2002-09-20 01:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611979&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Billy G. Allie (ballie01) Summary: CREATE DATABASE impossible? Initial Comment: It appears that the current code-base makes a create-database call impossible. Basically, the call can't happen within a transaction, so the default operation of wrapping everything in a transaction prevents the operation from working. I'm new to the project, but this would seem to be a minimal workaround: #378 re_CREATEDB = re.compile('[\s]*CREATE[\s]+DATABASE[\s]', re.I) #2518 _badQuery = re_CREATEDB.search(query) or ( (self.conn.version < 70100) and \ (re_DRT.search(query) or re_DRI.search(query) ) ) However, that doesn't address any other potential calls that need a non-transactional framework. Not sure how you'd want to do this in the general case (probably another method would be required). Enjoy, and thanks for the module, Mike ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-10-18 20:22 Message: Logged In: YES user_id=8500 With later versions of PostgreSQL, the number of things that have to be performed outside of a transaction has decreased. I would think that setting autocommit to 1 on the connection would be an acceptable solution for thoses operations that have to be outside of a transaction.. Your thoughts on this? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-20 01:30 Message: Logged In: YES user_id=163326 I'm not entirely sure what to do about this. You can (temporarily) set autocommit=1 to work around this: from pyPgSQL import PgSQL con = PgSQL.connect() con.autocommit = 1 cursor = con.cursor() cursor.execute("create database foo") con.close() ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2002-09-20 01:12 Message: Logged In: YES user_id=34901 Sorry, this report was from me, just forgot to log in first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611979&group_id=16528 |
|
From: <no...@so...> - 2002-10-19 00:09:02
|
Bugs item #625121, was opened at 2002-10-18 05:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Meisel (alex) >Assigned to: Billy G. Allie (ballie01) Summary: Error in corsur.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-10-18 20:08 Message: Logged In: YES user_id=8500 In regards to the rowcount problem, it is not a problem. Please see our FAQ at http://pypgsql.sourceforge.net/pypgsql-faq.html#id2781273 I will look into the testcase to see if I can figure out the problem with the Boolean constructor. Be warned that I do not have access to an alpha box, so I may not find out anything :-( Bill Allie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-18 09:47:37
|
Bugs item #625121, was opened at 2002-10-18 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 Category: PgBoolean Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Meisel (alex) Assigned to: Nobody/Anonymous (nobody) Summary: Error in corsur.rowcount Initial Comment: Hi, I'm using Redhat 7.2 on a alpha (not i386) with PostgreSQL 7.2.3. A simple query which actually succeeds gives a -1 back on cursor.rowcount ... My test scipt looks like this: --- #!/opt/bin/python2.2 from pyPgSQL import PgSQL c = PgSQL.connect('user=alex dbname=kerneldb host=localhost') c1 = c.cursor() c1.execute("SELECT * FROM project") print c1.rowcount data = c1.fetchall() print data --- The scripts output is: --- [alex@wormhole alex]$ ./dbtest.py -1 [[1, 'linux', '']] [alex@wormhole alex]$ --- I did run the test script in your source distributuion, it had the following output: --- bash-2.05$ python2.2 PgSQLTestCases.py .............F.................................................... ====================================================================== FAIL: CheckBooleanConstructors (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 167, in CheckBooleanConstructors 'PgBooleanFromInteger failed to create a FALSE value (1).') File "/opt/lib/python2.2/unittest.py", line 258, in failIf if expr: raise self.failureException, msg AssertionError: PgBooleanFromInteger failed to create a FALSE value (1). ---------------------------------------------------------------------- Ran 66 tests in 3.574s FAILED (failures=1) ---- Hope you can fix it soon ... or I have to abandom my lovely alpha and replace the db server with a horrible intel machine. :-( Thx in advance! Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=625121&group_id=16528 |
|
From: <no...@so...> - 2002-10-04 01:09:34
|
Support Requests item #617738, was opened at 2002-10-02 22:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 Category: PgSQL.py Group: None >Status: Closed Priority: 7 Submitted By: Benjamin Bruheim (phed) Assigned to: Gerhard Häring (ghaering) Summary: Unicode and debian Initial Comment: Are there any plans for support for UNICODE? At the moment I get "ASCII encoding error" when I try to send UNICODE. There is a patch for pypgsql 2.1 available, while the debian version I've obtained is 2.2. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-04 03:09 Message: Logged In: YES user_id=163326 Closing. This was cleared up in private email. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-03 16:37 Message: Logged In: YES user_id=163326 My plans are to have official unicode support in pyPgSQL 3.0, but not in the 2.x series. The reason is that I didn't get any feedback from users if they're happy with the API, despite asking multiple times. But perhaps I'll change my mind. Btw. the Unicode patch applies cleanly to pyPgSQL 2.2 and only applies to PgSQL.py and adds a test suite. You should be able to hack the patch file to get it running on your Debian binaries. Anyway, as you've just contacted me via email, I'll just send you a patched PgSQL.py file. cu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 |
|
From: <no...@so...> - 2002-10-03 14:37:50
|
Support Requests item #617738, was opened at 2002-10-02 22:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 Category: PgSQL.py Group: None Status: Open >Priority: 7 Submitted By: Benjamin Bruheim (phed) >Assigned to: Gerhard Häring (ghaering) Summary: Unicode and debian Initial Comment: Are there any plans for support for UNICODE? At the moment I get "ASCII encoding error" when I try to send UNICODE. There is a patch for pypgsql 2.1 available, while the debian version I've obtained is 2.2. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-03 16:37 Message: Logged In: YES user_id=163326 My plans are to have official unicode support in pyPgSQL 3.0, but not in the 2.x series. The reason is that I didn't get any feedback from users if they're happy with the API, despite asking multiple times. But perhaps I'll change my mind. Btw. the Unicode patch applies cleanly to pyPgSQL 2.2 and only applies to PgSQL.py and adds a test suite. You should be able to hack the patch file to get it running on your Debian binaries. Anyway, as you've just contacted me via email, I'll just send you a patched PgSQL.py file. cu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 |
|
From: <no...@so...> - 2002-10-03 14:37:14
|
Support Requests item #617738, was opened at 2002-10-02 22:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 Category: PgSQL.py Group: None Status: Open Priority: 5 Submitted By: Benjamin Bruheim (phed) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode and debian Initial Comment: Are there any plans for support for UNICODE? At the moment I get "ASCII encoding error" when I try to send UNICODE. There is a patch for pypgsql 2.1 available, while the debian version I've obtained is 2.2. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-03 16:37 Message: Logged In: YES user_id=163326 My plans are to have official unicode support in pyPgSQL 3.0, but not in the 2.x series. The reason is that I didn't get any feedback from users if they're happy with the API, despite asking multiple times. But perhaps I'll change my mind. Btw. the Unicode patch applies cleanly to pyPgSQL 2.2 and only applies to PgSQL.py and adds a test suite. You should be able to hack the patch file to get it running on your Debian binaries. Anyway, as you've just contacted me via email, I'll just send you a patched PgSQL.py file. cu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 |
|
From: <no...@so...> - 2002-10-03 14:31:31
|
Patches item #484468, was opened at 2001-11-22 07:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=484468&group_id=16528 Category: None Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Gerhard Häring (ghaering) Summary: Draft Unicode patch Initial Comment: Ok, here comes what I've done so far for adding Unicode support. Jjust to show what I've been talking about on the mailing list and by no means finished or bugfree. Bugs are (at least): - no checks if PostgreSQL multibyte support is available at all (compiles may perhaps fail) - for some reason, no exception is raised when setting the clientencoding fails ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-03 16:31 Message: Logged In: YES user_id=163326 The patch still applies cleanly to pyPgSQL 2.2. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-05 19:32 Message: Logged In: YES user_id=163326 I've now uploaded an updated patch that applies cleanly to pyPgSQL version 2.1. I'd be very grateful if those interested in Unicode support could test it and tell me (on the mailing list, preferrably) what should be done differently and which features are still missing, if any. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-04-16 05:18 Message: Logged In: YES user_id=163326 Hmm. The patch is pretty large. So one more comment: The only relevant addition is the __unicodeConvert() method in the Connection class. The other relevant changes can be found by grepping for "unicode". There's also cosmetic changes to the typechecking in this patch (always use "is" instead of "==" and "is not" instead of "!="). And also always compare to "None" with "is" - the comparison with "==" has bitten a pyPgSQL user once. The is-Check is more pythonic and slightly faster. Enough for today :) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-04-16 05:06 Message: Logged In: YES user_id=163326 I'm publishing here my update to the patch. This patch is against the latest CVS version of pyPgSQL. It turns out that changes to libpq are not necessary at all. Some testing code is already there and I'm pretty confident that I'm on the right track with the current approach. More later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=484468&group_id=16528 |
|
From: <no...@so...> - 2002-10-02 20:16:44
|
Support Requests item #617738, was opened at 2002-10-02 22:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 Category: PgSQL.py Group: None Status: Open Priority: 5 Submitted By: Benjamin Bruheim (phed) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode and debian Initial Comment: Are there any plans for support for UNICODE? At the moment I get "ASCII encoding error" when I try to send UNICODE. There is a patch for pypgsql 2.1 available, while the debian version I've obtained is 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=617738&group_id=16528 |
|
From: <no...@so...> - 2002-10-02 05:18:13
|
Bugs item #614129, was opened at 2002-09-25 02:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=614129&group_id=16528 Category: PgSQL Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Gerhard Häring (ghaering) Assigned to: Gerhard Häring (ghaering) Summary: Problems with INTERVAL type Initial Comment: Once an interval is greater than one day, you can an error like: File "/usr/lib/python2.1/site-packages/mx/DateTime/ISO.py", line 313, in ParseAny raise ValueError,'unsupported format: "%s"' % isostring ValueError: unsupported format: "1 day 00:30" ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-02 07:18 Message: Logged In: YES user_id=163326 Fixed in revision 1.17 of PgSQL.py. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:44 Message: Logged In: YES user_id=163326 I'll try to come up with a patch this weekend. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=614129&group_id=16528 |
|
From: <no...@so...> - 2002-10-02 04:55:18
|
Bugs item #589270, was opened at 2002-07-31 20:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=589270&group_id=16528 Category: PgInt8 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Billy G. Allie (ballie01) Summary: strtoll strtoull not in Compac C on OSF Initial Comment: The routines to convert strings to signed and unsigned long longs, strtoll, strtoull, do not seem to available in Compaq C V6.1-123 on Digital UNIX V4.0G (Rev. 1530) (and not part of ANSI C). The package then does not build properly on our ALPHA OSF 1 V4.0 1530. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-10-02 06:55 Message: Logged In: YES user_id=163326 Closing now. If the CVS version still doesn't work, please reopen the bug. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:46 Message: Logged In: YES user_id=163326 Building on your platform should work with the CVS version of pyPgSQL. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-08-02 03:40 Message: Logged In: YES user_id=8500 I think we should rename the functions to pg_strtoll and pg_strtoull and always use those. When can then avoid the special casing of setup.py as you suggested. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-01 09:15 Message: Logged In: YES user_id=163326 Billy, what do we do in this case? Use the stuff from the windows/ directory? Anonymous, could you please post what >>> import sys, os >>> print sys.platform >>> print os.name prints on your DEC machine? On a very old box I have access to, this prints: 'osf1V4' and 'posix'. Another possibility is to rename the functions in the windows/ directory, to avoid name conflicts with libc stuff on other platforms, and *always* use our own implementations. Maybe that's preferrable to special-case for the dozens of Unices out there. Anonymous, as a temporary workaround you can use the functions in the windows/ directory. You'll need to change setup.py so that these get linked in, just search for how it's done for the win32 platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=589270&group_id=16528 |
|
From: <no...@so...> - 2002-09-28 13:54:08
|
Support Requests item #615598, was opened at 2002-09-27 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=615598&group_id=16528 Category: PgSQL.py Group: None Status: Open Priority: 5 Submitted By: Wild Bill (wildbilly) Assigned to: Nobody/Anonymous (nobody) Summary: Unintuitive error messages Initial Comment: Hello, My python code looks like this: cursor.execute("""INSERT INTO table1 VALUES(%s, %s, %s, %s, %s, %s, %s)""", (iurl, tags2, val2, depth, val3, val4, val5)) And the error message looks like this: libpq.OperationalError ERROR: parser: parse error at or near "l" Which means absolutely nothing to me. I try some debugging code to see what the SQL looks like: print """INSERT INTO able1 VALUES(%s, %s, %s, %s, %s, %s, %s);""" % (iurl, tags2, val2, depth, val3, val4, val5) Which outputs INSERT INTO table1 VALUES(http://www.dmoz.org/Society/, 0, 3, 500, 50000, 200209271030, 0); Any thoughts? Does PgSQL module take care of backslashing, adding appropriate apostraphes, etc? I can't find any documentation on this anywhere. Thanks ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:54 Message: Logged In: YES user_id=163326 Using the % operator yourself doesn't help for debugging. Please activate SQL logging by accessing the toggleShowQuery attribute on the low-level connection attribute, something like this: from pyPgSQL import PgSQL con = PgSQL.connect(...) con.con.toggleShowQuery cursor = con.cursor() cursor.execute(...) Could you please post the SQL that gets sent to the backend? Btw. the libpq.OperationalError comes from the PostgreSQL backend. We can't do much about improving it. It just means PostgreSQL cannot parse the SQL statement it gets sent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=615598&group_id=16528 |
|
From: <no...@so...> - 2002-09-28 13:46:46
|
Bugs item #589270, was opened at 2002-07-31 20:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=589270&group_id=16528 Category: PgInt8 Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Billy G. Allie (ballie01) Summary: strtoll strtoull not in Compac C on OSF Initial Comment: The routines to convert strings to signed and unsigned long longs, strtoll, strtoull, do not seem to available in Compaq C V6.1-123 on Digital UNIX V4.0G (Rev. 1530) (and not part of ANSI C). The package then does not build properly on our ALPHA OSF 1 V4.0 1530. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:46 Message: Logged In: YES user_id=163326 Building on your platform should work with the CVS version of pyPgSQL. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-08-02 03:40 Message: Logged In: YES user_id=8500 I think we should rename the functions to pg_strtoll and pg_strtoull and always use those. When can then avoid the special casing of setup.py as you suggested. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-01 09:15 Message: Logged In: YES user_id=163326 Billy, what do we do in this case? Use the stuff from the windows/ directory? Anonymous, could you please post what >>> import sys, os >>> print sys.platform >>> print os.name prints on your DEC machine? On a very old box I have access to, this prints: 'osf1V4' and 'posix'. Another possibility is to rename the functions in the windows/ directory, to avoid name conflicts with libc stuff on other platforms, and *always* use our own implementations. Maybe that's preferrable to special-case for the dozens of Unices out there. Anonymous, as a temporary workaround you can use the functions in the windows/ directory. You'll need to change setup.py so that these get linked in, just search for how it's done for the win32 platform. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=589270&group_id=16528 |
|
From: <no...@so...> - 2002-09-28 13:45:04
|
Bugs item #611483, was opened at 2002-09-19 11:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611483&group_id=16528 Category: PgSQL Group: None >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Gerhard Häring (ghaering) Summary: NULL not represented by Python None Initial Comment: According to the Database API 2.0, "SQL NULL values are represented by the Python None singleton on input and output." This doesn't seem to be the case: INSERT INTO "XXX" ("foo", "bar", "baz", "bop") VALUES ('boo', None, None, None) Traceback (most recent call last): File "XXX.py", line 90, in ? print XYZ_add() File "XXX.py", line 33, in ZZZ self.add_XYZ() File "XXX.py", line 25, in YYY self.cursor.execute(SQL) File "/usr/lib/python2.1/site-packages/pyPgSQL/PgSQL.py", line 2135, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Attribute 'none' not found ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-19 14:18 Message: Logged In: YES user_id=163326 Don't put None literally in SQL. If you want NULL in a SQL string, put NULL in ;-) You can, however, use Python Nones when binding parameters to your SQL statement, like this: cursor.execute(""" INSERT INTO MYTABLE (MYCOLUMN) VALUES (%s) """, (None,)) HTH ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611483&group_id=16528 |
|
From: <no...@so...> - 2002-09-28 13:44:08
|
Bugs item #614129, was opened at 2002-09-25 02:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=614129&group_id=16528 Category: PgSQL Group: None Status: Open >Resolution: Accepted >Priority: 3 Submitted By: Gerhard Häring (ghaering) >Assigned to: Gerhard Häring (ghaering) Summary: Problems with INTERVAL type Initial Comment: Once an interval is greater than one day, you can an error like: File "/usr/lib/python2.1/site-packages/mx/DateTime/ISO.py", line 313, in ParseAny raise ValueError,'unsupported format: "%s"' % isostring ValueError: unsupported format: "1 day 00:30" ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:44 Message: Logged In: YES user_id=163326 I'll try to come up with a patch this weekend. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=614129&group_id=16528 |
|
From: <no...@so...> - 2002-09-28 13:42:13
|
Bugs item #615849, was opened at 2002-09-28 14:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=615849&group_id=16528 >Category: PgSQL Group: None >Status: Closed >Resolution: Invalid >Priority: 2 Submitted By: Ondrej Palkovsky (ondrap) >Assigned to: Gerhard Häring (ghaering) Summary: problems with Longs in queries Initial Comment: There is a problem with longs in queries, the _quote function incorrectly calls repr() instead of str() on long numbers (e.g. 1L ) and postgres does not like the appended 'L'. str(1L) -> '1', while repr(1L) -> '1L'. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-09-28 15:42 Message: Logged In: YES user_id=163326 This bug was already fixed in revision 1.11 of pyPgSQL/PgSQL.py a few months ago and is thus already fixed in pyPgSQL 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=615849&group_id=16528 |
|
From: <no...@so...> - 2002-09-28 12:41:17
|
Bugs item #615849, was opened at 2002-09-28 14:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=615849&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: problems with Longs in queries Initial Comment: There is a problem with longs in queries, the _quote function incorrectly calls repr() instead of str() on long numbers (e.g. 1L ) and postgres does not like the appended 'L'. str(1L) -> '1', while repr(1L) -> '1L'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=615849&group_id=16528 |
|
From: <no...@so...> - 2002-09-27 17:48:17
|
Support Requests item #615598, was opened at 2002-09-27 17:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=615598&group_id=16528 Category: PgSQL.py Group: None Status: Open Priority: 5 Submitted By: Wild Bill (wildbilly) Assigned to: Nobody/Anonymous (nobody) Summary: Unintuitive error messages Initial Comment: Hello, My python code looks like this: cursor.execute("""INSERT INTO table1 VALUES(%s, %s, %s, %s, %s, %s, %s)""", (iurl, tags2, val2, depth, val3, val4, val5)) And the error message looks like this: libpq.OperationalError ERROR: parser: parse error at or near "l" Which means absolutely nothing to me. I try some debugging code to see what the SQL looks like: print """INSERT INTO able1 VALUES(%s, %s, %s, %s, %s, %s, %s);""" % (iurl, tags2, val2, depth, val3, val4, val5) Which outputs INSERT INTO table1 VALUES(http://www.dmoz.org/Society/, 0, 3, 500, 50000, 200209271030, 0); Any thoughts? Does PgSQL module take care of backslashing, adding appropriate apostraphes, etc? I can't find any documentation on this anywhere. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=216528&aid=615598&group_id=16528 |
|
From: <no...@so...> - 2002-09-25 00:38:23
|
Bugs item #614129, was opened at 2002-09-25 02:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=614129&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with INTERVAL type Initial Comment: Once an interval is greater than one day, you can an error like: File "/usr/lib/python2.1/site-packages/mx/DateTime/ISO.py", line 313, in ParseAny raise ValueError,'unsupported format: "%s"' % isostring ValueError: unsupported format: "1 day 00:30" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=614129&group_id=16528 |
|
From: <no...@so...> - 2002-09-20 05:30:26
|
Bugs item #611979, was opened at 2002-09-20 07:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611979&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Billy G. Allie (ballie01) Summary: CREATE DATABASE impossible? Initial Comment: It appears that the current code-base makes a create-database call impossible. Basically, the call can't happen within a transaction, so the default operation of wrapping everything in a transaction prevents the operation from working. I'm new to the project, but this would seem to be a minimal workaround: #378 re_CREATEDB = re.compile('[\s]*CREATE[\s]+DATABASE[\s]', re.I) #2518 _badQuery = re_CREATEDB.search(query) or ( (self.conn.version < 70100) and \ (re_DRT.search(query) or re_DRI.search(query) ) ) However, that doesn't address any other potential calls that need a non-transactional framework. Not sure how you'd want to do this in the general case (probably another method would be required). Enjoy, and thanks for the module, Mike ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-09-20 07:30 Message: Logged In: YES user_id=163326 I'm not entirely sure what to do about this. You can (temporarily) set autocommit=1 to work around this: from pyPgSQL import PgSQL con = PgSQL.connect() con.autocommit = 1 cursor = con.cursor() cursor.execute("create database foo") con.close() ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2002-09-20 07:12 Message: Logged In: YES user_id=34901 Sorry, this report was from me, just forgot to log in first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611979&group_id=16528 |
1 message has been excluded from this view by a project administrator.
