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-11-30 05:43:27
|
Bugs item #645830, was opened at 2002-11-29 15:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=645830&group_id=16528 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) >Assigned to: Billy G. Allie (ballie01) Summary: DateTime for postgres 7.2.3 Initial Comment: I have tried to access postgres 7.2.3 'datetime' (timestamp without time zone) type and always received a string from pgsql. I had to add type '1114' to the DBApiTypeObject DATETIME definition. I didn't find such constant in libpq so I guess it would need to be added there too. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-11-30 00:43 Message: Logged In: YES user_id=8500 7.2.3 brought into being a new type (TIMESTAMPTZOID) that didn't get put into pyPgSQL. It also changed the OID used for TIMESTAMP. I will be fixing tis problem and adding support for reference cursors shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=645830&group_id=16528 |
|
From: <no...@so...> - 2002-11-29 20:32:34
|
Bugs item #645830, was opened at 2002-11-29 21:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=645830&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: DateTime for postgres 7.2.3 Initial Comment: I have tried to access postgres 7.2.3 'datetime' (timestamp without time zone) type and always received a string from pgsql. I had to add type '1114' to the DBApiTypeObject DATETIME definition. I didn't find such constant in libpq so I guess it would need to be added there too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=645830&group_id=16528 |
|
From: <no...@so...> - 2002-11-25 02:14:06
|
Patches item #631396, was opened at 2002-10-31 06:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Gerhard Häring (ghaering) Summary: Gentoo Linux patch Initial Comment: This file patches setup.py to work correctly with Gentoo Linux 1.4_rc1. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-04 09:17 Message: Logged In: YES user_id=163326 Thanks for the pach. However: elif distribution == 'Gentoo': cfg.include_dirs = ['/usr/include/pyPgSQL'] cfg.library_dirs = ['/usr/lib'] is this meant to work? I somehow doubt that the directory with the PostgreSQL header files is called '/usr/include/pyPgSQL', even on Gentoo Linux ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 |
|
From: <no...@so...> - 2002-11-13 22:34:46
|
Bugs item #634540, was opened at 2002-11-06 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 Category: PgSQL Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Petter Reinholdtsen (pere) Assigned to: Gerhard Häring (ghaering) Summary: Unable to insert UTF-8 strings Initial Comment: I'm unable to insert an python UTF-8 string into my UTF-8 PostgreSQL database. This is the error message: Traceback (most recent call last): File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/tests/SQLDriverTestCase.py", line 37, in testUTF8Text {'text': u"unicodeTest"}) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 603, in execute return self._cursor.execute(operation, parameters) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 184, in execute return self._cursor.execute(sql, *binds) File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2590, in execute raise OperationalError, msg OperationalError: ERROR: Unable to locate type name 'u' in catalog This is a fragment from the test code that fails: self.db.execute("CREATE TABLE test_db_utf8 (value CHAR VARYING(128))") self.db.execute("INSERT INTO test_db_utf8 (value) VALUES (:text)", {'text': u"unicodeTest"}) self.db.execute("DROP TABLE test_db_utf8") ---------------------------------------------------------------------- Comment By: Petter Reinholdtsen (pere) Date: 2002-11-13 20:00 Message: Logged In: YES user_id=81008 The CVS version works just fine. Thanks. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-07 04:29 Message: Logged In: YES user_id=163326 Could you please try the current 2.3 beta or -CVS? Unicode wasn't supported in earlier versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 |
|
From: <no...@so...> - 2002-11-13 22:34:03
|
Bugs item #634542, was opened at 2002-11-06 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 Category: PgSQL Group: None >Status: Closed Resolution: Fixed Priority: 7 Submitted By: Petter Reinholdtsen (pere) Assigned to: Billy G. Allie (ballie01) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- Comment By: Petter Reinholdtsen (pere) Date: 2002-11-13 20:00 Message: Logged In: YES user_id=81008 It works just fine. :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-12 05:56 Message: Logged In: YES user_id=8500 This problem has been fixed in the latest (CVS) version of PgSQL.py. Can you test this change Petter? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-07 05:21 Message: Logged In: YES user_id=8500 I'll take this one Gerhard ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-07 04:36 Message: Logged In: YES user_id=163326 Ah. You are getting a PgNumeric, which currently isn't hashable. Billy, do you want to handle this? Otherwise I'll give it a try eventually. Or alternatively, Petter, a patch for this would be most welcome :-) As a temporary workaround, you can perhaps convert the PgNumeric to a float or a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-13 19:00:48
|
Bugs item #634540, was opened at 2002-11-06 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Petter Reinholdtsen (pere) Assigned to: Gerhard Häring (ghaering) Summary: Unable to insert UTF-8 strings Initial Comment: I'm unable to insert an python UTF-8 string into my UTF-8 PostgreSQL database. This is the error message: Traceback (most recent call last): File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/tests/SQLDriverTestCase.py", line 37, in testUTF8Text {'text': u"unicodeTest"}) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 603, in execute return self._cursor.execute(operation, parameters) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 184, in execute return self._cursor.execute(sql, *binds) File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2590, in execute raise OperationalError, msg OperationalError: ERROR: Unable to locate type name 'u' in catalog This is a fragment from the test code that fails: self.db.execute("CREATE TABLE test_db_utf8 (value CHAR VARYING(128))") self.db.execute("INSERT INTO test_db_utf8 (value) VALUES (:text)", {'text': u"unicodeTest"}) self.db.execute("DROP TABLE test_db_utf8") ---------------------------------------------------------------------- >Comment By: Petter Reinholdtsen (pere) Date: 2002-11-13 20:00 Message: Logged In: YES user_id=81008 The CVS version works just fine. Thanks. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-07 04:29 Message: Logged In: YES user_id=163326 Could you please try the current 2.3 beta or -CVS? Unicode wasn't supported in earlier versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 |
|
From: <no...@so...> - 2002-11-13 19:00:07
|
Bugs item #634542, was opened at 2002-11-06 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Petter Reinholdtsen (pere) Assigned to: Billy G. Allie (ballie01) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- >Comment By: Petter Reinholdtsen (pere) Date: 2002-11-13 20:00 Message: Logged In: YES user_id=81008 It works just fine. :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-12 05:56 Message: Logged In: YES user_id=8500 This problem has been fixed in the latest (CVS) version of PgSQL.py. Can you test this change Petter? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-07 05:21 Message: Logged In: YES user_id=8500 I'll take this one Gerhard ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-07 04:36 Message: Logged In: YES user_id=163326 Ah. You are getting a PgNumeric, which currently isn't hashable. Billy, do you want to handle this? Otherwise I'll give it a try eventually. Or alternatively, Petter, a patch for this would be most welcome :-) As a temporary workaround, you can perhaps convert the PgNumeric to a float or a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-12 04:57:02
|
Bugs item #634542, was opened at 2002-11-06 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 >Category: PgSQL Group: None Status: Open >Resolution: Fixed Priority: 7 Submitted By: Petter Reinholdtsen (pere) Assigned to: Billy G. Allie (ballie01) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-11 23:56 Message: Logged In: YES user_id=8500 This problem has been fixed in the latest (CVS) version of PgSQL.py. Can you test this change Petter? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-06 23:21 Message: Logged In: YES user_id=8500 I'll take this one Gerhard ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-06 22:36 Message: Logged In: YES user_id=163326 Ah. You are getting a PgNumeric, which currently isn't hashable. Billy, do you want to handle this? Otherwise I'll give it a try eventually. Or alternatively, Petter, a patch for this would be most welcome :-) As a temporary workaround, you can perhaps convert the PgNumeric to a float or a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-12 04:56:18
|
Bugs item #634542, was opened at 2002-11-06 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 7 Submitted By: Petter Reinholdtsen (pere) Assigned to: Billy G. Allie (ballie01) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-11-11 23:56 Message: Logged In: YES user_id=8500 This problem has been fixed in the latest (CVS) version of PgSQL.py. Can you test this change Petter? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-06 23:21 Message: Logged In: YES user_id=8500 I'll take this one Gerhard ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-06 22:36 Message: Logged In: YES user_id=163326 Ah. You are getting a PgNumeric, which currently isn't hashable. Billy, do you want to handle this? Otherwise I'll give it a try eventually. Or alternatively, Petter, a patch for this would be most welcome :-) As a temporary workaround, you can perhaps convert the PgNumeric to a float or a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-12 04:53:54
|
Bugs item #636368, was opened at 2002-11-10 17:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&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: insert with longinteger value Initial Comment: in an insert statement, a python long integer value like 1010L results in a parser error (something like "parser error at l". After conversion to a normal integer value with int() everything works fine. There will be a problem with very large integer values which can not be converted with int(). The error occured with the latest beta version. Pythonversion was 2.2.2, PostgreSQL- Version was 7.2.3 Christoph Becker ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-11-11 23:53 Message: Logged In: YES user_id=8500 This is not a problem with pyPgSQL. A Python long does not map to a PostgreSQL data type, so you must cast it to the appropiate type. For example, if the field you are trying to insert into is an integer8, you would use PgInt8(longvalue). If it is an integer, then int(longvalue) would do it. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-11 17:28 Message: Logged In: YES user_id=163326 Sorry, can't reproduce here: >>> cursor.execute("select * from test where a=%s", (10L**15,)) >>> print cursor.fetchone() [1000000000000000L] Please upload a test case that demonstrates the problem. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-11 11:00 Message: Logged In: YES user_id=163326 Hmm. I thought I fixed that for 2.3beta1. Plan to check it later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 |
|
From: <no...@so...> - 2002-11-11 22:28:22
|
Bugs item #636368, was opened at 2002-11-10 23:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Gerhard Häring (ghaering) Summary: insert with longinteger value Initial Comment: in an insert statement, a python long integer value like 1010L results in a parser error (something like "parser error at l". After conversion to a normal integer value with int() everything works fine. There will be a problem with very large integer values which can not be converted with int(). The error occured with the latest beta version. Pythonversion was 2.2.2, PostgreSQL- Version was 7.2.3 Christoph Becker ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-11-11 23:28 Message: Logged In: YES user_id=163326 Sorry, can't reproduce here: >>> cursor.execute("select * from test where a=%s", (10L**15,)) >>> print cursor.fetchone() [1000000000000000L] Please upload a test case that demonstrates the problem. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-11 17:00 Message: Logged In: YES user_id=163326 Hmm. I thought I fixed that for 2.3beta1. Plan to check it later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 |
|
From: <no...@so...> - 2002-11-11 16:00:49
|
Bugs item #636368, was opened at 2002-11-10 23:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 >Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Gerhard Häring (ghaering) Summary: insert with longinteger value Initial Comment: in an insert statement, a python long integer value like 1010L results in a parser error (something like "parser error at l". After conversion to a normal integer value with int() everything works fine. There will be a problem with very large integer values which can not be converted with int(). The error occured with the latest beta version. Pythonversion was 2.2.2, PostgreSQL- Version was 7.2.3 Christoph Becker ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-11-11 17:00 Message: Logged In: YES user_id=163326 Hmm. I thought I fixed that for 2.3beta1. Plan to check it later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 |
|
From: <no...@so...> - 2002-11-10 22:31:45
|
Bugs item #636368, was opened at 2002-11-10 14:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: insert with longinteger value Initial Comment: in an insert statement, a python long integer value like 1010L results in a parser error (something like "parser error at l". After conversion to a normal integer value with int() everything works fine. There will be a problem with very large integer values which can not be converted with int(). The error occured with the latest beta version. Pythonversion was 2.2.2, PostgreSQL- Version was 7.2.3 Christoph Becker ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=636368&group_id=16528 |
|
From: <no...@so...> - 2002-11-07 04:21:16
|
Bugs item #634542, was opened at 2002-11-06 12:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Petter Reinholdtsen (pere) >Assigned to: Billy G. Allie (ballie01) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-11-06 23:21 Message: Logged In: YES user_id=8500 I'll take this one Gerhard ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-06 22:36 Message: Logged In: YES user_id=163326 Ah. You are getting a PgNumeric, which currently isn't hashable. Billy, do you want to handle this? Otherwise I'll give it a try eventually. Or alternatively, Petter, a patch for this would be most welcome :-) As a temporary workaround, you can perhaps convert the PgNumeric to a float or a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-07 03:36:23
|
Bugs item #634542, was opened at 2002-11-06 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 5 Submitted By: Petter Reinholdtsen (pere) Assigned to: Nobody/Anonymous (nobody) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-11-07 04:36 Message: Logged In: YES user_id=163326 Ah. You are getting a PgNumeric, which currently isn't hashable. Billy, do you want to handle this? Otherwise I'll give it a try eventually. Or alternatively, Petter, a patch for this would be most welcome :-) As a temporary workaround, you can perhaps convert the PgNumeric to a float or a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-07 03:29:56
|
Bugs item #634540, was opened at 2002-11-06 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Petter Reinholdtsen (pere) >Assigned to: Gerhard Häring (ghaering) Summary: Unable to insert UTF-8 strings Initial Comment: I'm unable to insert an python UTF-8 string into my UTF-8 PostgreSQL database. This is the error message: Traceback (most recent call last): File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/tests/SQLDriverTestCase.py", line 37, in testUTF8Text {'text': u"unicodeTest"}) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 603, in execute return self._cursor.execute(operation, parameters) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 184, in execute return self._cursor.execute(sql, *binds) File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2590, in execute raise OperationalError, msg OperationalError: ERROR: Unable to locate type name 'u' in catalog This is a fragment from the test code that fails: self.db.execute("CREATE TABLE test_db_utf8 (value CHAR VARYING(128))") self.db.execute("INSERT INTO test_db_utf8 (value) VALUES (:text)", {'text': u"unicodeTest"}) self.db.execute("DROP TABLE test_db_utf8") ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-11-07 04:29 Message: Logged In: YES user_id=163326 Could you please try the current 2.3 beta or -CVS? Unicode wasn't supported in earlier versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 |
|
From: <no...@so...> - 2002-11-06 17:12:09
|
Bugs item #634542, was opened at 2002-11-06 18:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 5 Submitted By: Petter Reinholdtsen (pere) Assigned to: Nobody/Anonymous (nobody) Summary: SQL integer is not hashable Initial Comment: I'm unable to use a numeric value as the key in a dictioary. This is the error message: Traceback (most recent call last): File "Cerebrum/tests/SQLDriverTestCase.py", line 30, in testSQLIntHashable hash[value] = 1 TypeError: unhashable instance This is a fragment of the test code that fails: self.db.execute("CREATE TABLE test_db_dict (value NUMERIC(6,0))") self.db.execute("INSERT INTO test_db_dict (value) VALUES (1)") value = self.db.query_1("SELECT max(value) FROM test_db_dict") hash = {} hash[value] = 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634542&group_id=16528 |
|
From: <no...@so...> - 2002-11-06 17:08:09
|
Bugs item #634540, was opened at 2002-11-06 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Petter Reinholdtsen (pere) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to insert UTF-8 strings Initial Comment: I'm unable to insert an python UTF-8 string into my UTF-8 PostgreSQL database. This is the error message: Traceback (most recent call last): File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/tests/SQLDriverTestCase.py", line 37, in testUTF8Text {'text': u"unicodeTest"}) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 603, in execute return self._cursor.execute(operation, parameters) File "/usit/saruman/bsd-u1/pre/usit/src/cerebrumcvs/cerebrum/Cerebrum/Database.py", line 184, in execute return self._cursor.execute(sql, *binds) File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2590, in execute raise OperationalError, msg OperationalError: ERROR: Unable to locate type name 'u' in catalog This is a fragment from the test code that fails: self.db.execute("CREATE TABLE test_db_utf8 (value CHAR VARYING(128))") self.db.execute("INSERT INTO test_db_utf8 (value) VALUES (:text)", {'text': u"unicodeTest"}) self.db.execute("DROP TABLE test_db_utf8") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=634540&group_id=16528 |
|
From: <no...@so...> - 2002-11-04 08:18:18
|
Patches item #631396, was opened at 2002-10-31 06:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Gerhard Häring (ghaering) Summary: Gentoo Linux patch Initial Comment: This file patches setup.py to work correctly with Gentoo Linux 1.4_rc1. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-11-04 09:17 Message: Logged In: YES user_id=163326 Thanks for the pach. However: elif distribution == 'Gentoo': cfg.include_dirs = ['/usr/include/pyPgSQL'] cfg.library_dirs = ['/usr/lib'] is this meant to work? I somehow doubt that the directory with the PostgreSQL header files is called '/usr/include/pyPgSQL', even on Gentoo Linux ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 |
|
From: <no...@so...> - 2002-11-04 08:17:43
|
Patches item #631396, was opened at 2002-10-31 06:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Gentoo Linux patch Initial Comment: This file patches setup.py to work correctly with Gentoo Linux 1.4_rc1. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-11-04 09:17 Message: Logged In: YES user_id=163326 Thanks for the pach. However: elif distribution == 'Gentoo': cfg.include_dirs = ['/usr/include/pyPgSQL'] cfg.library_dirs = ['/usr/lib'] is this meant to work? I somehow doubt that the directory with the PostgreSQL header files is called '/usr/include/pyPgSQL', even on Gentoo Linux ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 |
|
From: <no...@so...> - 2002-10-31 05:11:22
|
Patches item #631396, was opened at 2002-10-30 21:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Gentoo Linux patch Initial Comment: This file patches setup.py to work correctly with Gentoo Linux 1.4_rc1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=631396&group_id=16528 |
|
From: <no...@so...> - 2002-10-27 04:02:27
|
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: Closed Resolution: Accepted 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-27 05:02 Message: Logged In: YES user_id=163326 Applied in revision 1.18 of PgSQL.py. ---------------------------------------------------------------------- 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-21 02:31:06
|
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: Postponed Priority: 2 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-20 22:31 Message: Logged In: YES user_id=8500 At least the re_DRT and re_DRI checks. These are only needed for PostgreSQL versions less then 7.1, so they can definitely go in pyPgSQL 3.0. They can go in future versions of 2.x if we decide to drop support for versions of PostgreSQL erlier than 7.1. It would sure simplify the logic of that section of code :-) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-20 17:26 Message: Logged In: YES user_id=163326 I'd say keep it as it is for now, mainly because I don't feel like implementing this and testing it with PostgreSQL 7.0 through 7.3 for the next release. Billy, your suggestion would be fine with me. Does this mean we could then remove the existing checks for DDL statements and just add an according note to the docs? ---------------------------------------------------------------------- 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-20 21:26:28
|
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: Postponed >Priority: 2 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-10-20 23:26 Message: Logged In: YES user_id=163326 I'd say keep it as it is for now, mainly because I don't feel like implementing this and testing it with PostgreSQL 7.0 through 7.3 for the next release. Billy, your suggestion would be fine with me. Does this mean we could then remove the existing checks for DDL statements and just add an according note to the docs? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-19 02: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 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 |
|
From: <no...@so...> - 2002-10-20 17:23:09
|
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: Pending >Resolution: Accepted 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 |
1 message has been excluded from this view by a project administrator.
