Menu
▾
▴
pypgsql-devel — List for discussion of pyPgSQL development.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(4) |
Aug
(9) |
Sep
(22) |
Oct
(21) |
Nov
(20) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(5) |
Mar
(30) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(13) |
Nov
(7) |
Dec
(11) |
| 2004 |
Jan
(5) |
Feb
(6) |
Mar
(6) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(10) |
Aug
(17) |
Sep
(6) |
Oct
(10) |
Nov
(3) |
Dec
|
| 2005 |
Jan
(1) |
Feb
(29) |
Mar
(6) |
Apr
(5) |
May
(5) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(27) |
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(7) |
| 2008 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2004-08-25 14:45:03
|
Bugs item #1016026, was opened at 2004-08-25 16:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016026&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 5 Submitted By: Laurent Mignon (mignonlm) Assigned to: Nobody/Anonymous (nobody) Summary: __unicodeConvert not recursive (class cursor) Initial Comment: if a list item is a list of unicode value -> crash def __unicodeConvert(self, obj): if type(obj) is StringType: return obj elif type(obj) is UnicodeType: return obj.encode (*self.conn.client_encoding) elif type(obj) in (ListType, TupleType): converted_obj = [] for item in obj: if type(item) is UnicodeType: converted_obj.append(item.encode (*self.conn.client_encoding)) elif type(item) in (ListType, TupleType): #add recursive routine converted_obj.append (self.__unicodeConvert(item)) else: converted_obj.append(item) return converted_obj elif type(obj) is DictType: converted_obj = {} for k, v in obj.items(): if type(v) is UnicodeType: converted_obj[k] = v.encode (*self.conn.client_encoding) else: converted_obj[k] = v return converted_obj elif isinstance(obj, PgResultSet): obj = copy.copy(obj) for k, v in obj.items(): if type(v) is UnicodeType: obj[k] = v.encode (*self.conn.client_encoding) return obj else: return obj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016026&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-25 14:25:40
|
Bugs item #1016010, was opened at 2004-08-25 16:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016010&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 5 Submitted By: Laurent Mignon (mignonlm) Assigned to: Nobody/Anonymous (nobody) Summary: __unicodeConvert not recursive (class cursor) Initial Comment: if a list item is a list of unicode value -> crash def __unicodeConvert(self, obj): if type(obj) is StringType: return obj elif type(obj) is UnicodeType: return obj.encode (*self.conn.client_encoding) elif type(obj) in (ListType, TupleType): converted_obj = [] for item in obj: if type(item) is UnicodeType: converted_obj.append(item.encode (*self.conn.client_encoding)) elif type(item) in (ListType, TupleType): #add recursive routine converted_obj.append (self.__unicodeConvert(item)) else: converted_obj.append(item) return converted_obj elif type(obj) is DictType: converted_obj = {} for k, v in obj.items(): if type(v) is UnicodeType: converted_obj[k] = v.encode (*self.conn.client_encoding) else: converted_obj[k] = v return converted_obj elif isinstance(obj, PgResultSet): obj = copy.copy(obj) for k, v in obj.items(): if type(v) is UnicodeType: obj[k] = v.encode (*self.conn.client_encoding) return obj else: return obj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016010&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-25 14:20:09
|
Bugs item #1016005, was opened at 2004-08-25 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016005&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Laurent Mignon (mignonlm) Assigned to: Nobody/Anonymous (nobody) Summary: _quote function enhancement Initial Comment: _quote function does not support unicode type as value and don't format list and tuple with postgrsql specific keyword 'ARRAY...' def _quote(value): if value is None: return 'NULL' elif hasattr(value, '_quote'): return value._quote() elif type(value) is DateTimeType: return "'%s'" % value elif type(value) is DateTimeDeltaType: return "'%s'" % dateTimeDelta2Interval(value) elif isinstance(value, (UnicodeType,StringType)): #Value - Add UnicodeType return PgQuoteString(value) elif isinstance(value, LongType): return str(value) elif type(value) in [ListType, TupleType]: # List - Added part n = len(value) if n == 0: return "NULL" s = '' for i in value: if s: s = s + ', ' s = s + _quote(i) return "ARRAY[" + s + "]" # List- end else: return repr(value) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016005&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-25 11:20:59
|
Bugs item #1006782, was opened at 2004-08-10 20:49 Message generated for change (Comment added) made by ghum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- >Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:19 Message: Logged In: YES user_id=665785 Thank you very much, mfuhr... I looked at the "devel" check and propose to do if (pgstricmp(last, "beta", 4) == 0) return (errno != 0); instead of strncmp ... I suppose the PostgreSQL developers had their reason to provide their own strcmp, or? ---------------------------------------------------------------------- Comment By: Michael Fuhr (mfuhr) Date: 2004-08-24 05:47 Message: Logged In: YES user_id=655499 PgVersion_New() calls parseToken(), which doesn't allow for the string "beta" in the last token of "8.0.0beta1". parseToken() checks for "devel" and a few other cases, but not for "beta". I got it to work by adding the following lines after the check for "devel": if (strncmp(last, "beta", 4) == 0) return (errno != 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-25 11:20:59
|
Bugs item #1006782, was opened at 2004-08-10 20:49 Message generated for change (Comment added) made by ghum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- >Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:19 Message: Logged In: YES user_id=665785 Thank you very much, mfuhr... I looked at the "devel" check and propose to do if (pgstricmp(last, "beta", 4) == 0) return (errno != 0); instead of strncmp ... I suppose the PostgreSQL developers had their reason to provide their own strcmp, or? ---------------------------------------------------------------------- Comment By: Michael Fuhr (mfuhr) Date: 2004-08-24 05:47 Message: Logged In: YES user_id=655499 PgVersion_New() calls parseToken(), which doesn't allow for the string "beta" in the last token of "8.0.0beta1". parseToken() checks for "devel" and a few other cases, but not for "beta". I got it to work by adding the following lines after the check for "devel": if (strncmp(last, "beta", 4) == 0) return (errno != 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-25 11:19:20
|
Bugs item #1006782, was opened at 2004-08-10 20:49 Message generated for change (Comment added) made by ghum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- >Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:19 Message: Logged In: YES user_id=665785 Thank you very much, mfuhr... I looked at the "devel" check and propose to do if (pgstricmp(last, "beta", 4) == 0) return (errno != 0); instead of strncmp ... I suppose the PostgreSQL developers had their reason to provide their own strcmp, or? ---------------------------------------------------------------------- Comment By: Michael Fuhr (mfuhr) Date: 2004-08-24 05:47 Message: Logged In: YES user_id=655499 PgVersion_New() calls parseToken(), which doesn't allow for the string "beta" in the last token of "8.0.0beta1". parseToken() checks for "devel" and a few other cases, but not for "beta". I got it to work by adding the following lines after the check for "devel": if (strncmp(last, "beta", 4) == 0) return (errno != 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-24 03:47:40
|
Bugs item #1006782, was opened at 2004-08-10 12:49 Message generated for change (Comment added) made by mfuhr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- Comment By: Michael Fuhr (mfuhr) Date: 2004-08-23 21:47 Message: Logged In: YES user_id=655499 PgVersion_New() calls parseToken(), which doesn't allow for the string "beta" in the last token of "8.0.0beta1". parseToken() checks for "devel" and a few other cases, but not for "beta". I got it to work by adding the following lines after the check for "devel": if (strncmp(last, "beta", 4) == 0) return (errno != 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-10 18:49:56
|
Bugs item #1006782, was opened at 2004-08-10 20:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-09 17:28:42
|
Bugs item #1005037, was opened at 2004-08-07 09:26 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Millman (frankmillman) >Assigned to: Gerhard Häring (ghaering) Summary: Problem with pgInt8 not defined Initial Comment: This is a copy of a message sent to comp.lang.python regarding a possible bug in pgPySQL. It is rather long, but I have reproduced it verbatim as any/all of it may be significant. Thanks. Below is the text of a message I was about to send in connection with an obscure problem. I have now almost got to the bottom of it, and am fairly confident that it is a bug in pyPgSQL. I hope this is the correct place to report such bugs. If not, please advise the correct forum. I have left the original message intact as it provides important information. At the bottom, I have recorded the new information that I have discovered. ------------------------------------------------------ ------------------------- Here is an obscure problem. I am not sure if I can explain the symptoms properly, but I will do my best. I have a Linux box (RH9) and an MSW box (W2K Pro) networked to each other. Both are running Python 2.3.3. Linux is the server. It is running PostgreSQL, which listens on port 5432. It is also running a socket server program that I have written using socket.socket(), listening on port 6543. I am using pyPgSQL to connect to the database. MSW is the client. From time to time it sends messages to my socket server. Messages are strings consisting of a single digit identifier, followed by a cPickle'd tuple containing various data fields. The client uses cPickle.dumps to prepare the string before sending, and the server uses cPickle.loads to unpickle it after receiving. Most times it works perfectly, but in one particular situation the server terminates with an error. The error is consistent - it always gives the same error resulting from the same message. However, I do not think it is caused by the message itself, as exactly the same message is sent in different circumstances without generating an error. The traceback is as follows - File "./chag_server.py", line 190, in ? dat = cPickle.loads(data[1:]) File "/usr/local/lib/python2.3/site- packages/pyPgSQL/libpq/__init__.py", line 43, in _I8 return PgInt8(value) NameError: ("global name 'PgInt8' is not defined", <function _I8 at 0x403a04c4>, ('17',)) The error occurs at the point of unpickling - I have moved this around, and it always fails at this point. A typical example of the tuple being unpickled is (2,'Ar',17,1) - it is all normal strings and integers. I have no idea why pyPgSQL is involved at all - I am certainly not invoking it directly. In fact the error comes from my server program, and that does not even import pyPgSQL. Here are the relevant lines from pyPgSQL/libpq/__init__.py - from libpq import * from libpq import __version__ HAVE_LONG_LONG_SUPPORT = dir().count('PgInt8') == 1 #-------------------------------------------------- -------------+ # Add support to pickle the following pyPgSQL objects: | # PgInt2, PgInt8, PgBoolean | #-------------------------------------------------- -------------+ def _B(value): return PgBoolean(value) def _I2(value): return PgInt2(value) def _I8(value): return PgInt8(value) Somehow pyPgSQL is responding to my unpickling command, and raising an error because PgInt8 is not defined. Here is another fact, which may provide a clue or may add confusion. If I run exactly the same program from the Linux box, using it as the client as well as the server, the error does not appear. I connect via the external IP address, not via 127.0.0.1, so I would have thought it would behave the same, but it does not. ------------------------------------------------------ ------------------------- Ok, here is the reason. I mentioned above that a typical tuple consists of (2,'Ar',17,1). I have found that under some circumstances the 3rd element is of type 'long' instead of type 'int', and this is what generates the error. Whether it is a long or an int is determined by pyPgSQL itself. It is a column value, where the column is of type 'serial', which means that PostgreSQL will generate a next number if the row is being inserted. If the row exists, the column value is returned along with all the other columns, and is returned as type int. If the row does not exist, I insert it, and then to retrieve the id generated, I have the following piece of code - cur = db.cursor() cur.execute("select currval('%s_%s_Seq')" % (tableid,columnid) ) rowid = cur.fetchone()[0] In this case, rowid contains the correct value, but is of type long. So this raises various questions - Why is PgInt8 not defined? Why does pyPgSQL affect my server program, which does not import any of pyPgSQL? Why does the error only occur when I connect from a remote machine? Now that I have identified the problem, I can work around it, so this has become a matter of correctness rather than a matter of urgency. Frank Millman ---------------------------------------------------------------------- Comment By: Frank Millman (frankmillman) Date: 2004-08-09 11:29 Message: Logged In: YES user_id=1070042 Apologies - my diagnosis was not quite correct. What is actually happening is as follows. Refer to the lines where I retrieve the id generated, ending with "rowid = cur.fetchone()[0]" If this line is executed from a Linux machine, rowid's type is "long". If it is executed from a Windows machine, rowid's type is "PgInt8". This explains why the error only occurs when I connect from the Windows machine. Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-09 09:29:44
|
Bugs item #1005037, was opened at 2004-08-07 07:26 Message generated for change (Comment added) made by frankmillman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with pgInt8 not defined Initial Comment: This is a copy of a message sent to comp.lang.python regarding a possible bug in pgPySQL. It is rather long, but I have reproduced it verbatim as any/all of it may be significant. Thanks. Below is the text of a message I was about to send in connection with an obscure problem. I have now almost got to the bottom of it, and am fairly confident that it is a bug in pyPgSQL. I hope this is the correct place to report such bugs. If not, please advise the correct forum. I have left the original message intact as it provides important information. At the bottom, I have recorded the new information that I have discovered. ------------------------------------------------------ ------------------------- Here is an obscure problem. I am not sure if I can explain the symptoms properly, but I will do my best. I have a Linux box (RH9) and an MSW box (W2K Pro) networked to each other. Both are running Python 2.3.3. Linux is the server. It is running PostgreSQL, which listens on port 5432. It is also running a socket server program that I have written using socket.socket(), listening on port 6543. I am using pyPgSQL to connect to the database. MSW is the client. From time to time it sends messages to my socket server. Messages are strings consisting of a single digit identifier, followed by a cPickle'd tuple containing various data fields. The client uses cPickle.dumps to prepare the string before sending, and the server uses cPickle.loads to unpickle it after receiving. Most times it works perfectly, but in one particular situation the server terminates with an error. The error is consistent - it always gives the same error resulting from the same message. However, I do not think it is caused by the message itself, as exactly the same message is sent in different circumstances without generating an error. The traceback is as follows - File "./chag_server.py", line 190, in ? dat = cPickle.loads(data[1:]) File "/usr/local/lib/python2.3/site- packages/pyPgSQL/libpq/__init__.py", line 43, in _I8 return PgInt8(value) NameError: ("global name 'PgInt8' is not defined", <function _I8 at 0x403a04c4>, ('17',)) The error occurs at the point of unpickling - I have moved this around, and it always fails at this point. A typical example of the tuple being unpickled is (2,'Ar',17,1) - it is all normal strings and integers. I have no idea why pyPgSQL is involved at all - I am certainly not invoking it directly. In fact the error comes from my server program, and that does not even import pyPgSQL. Here are the relevant lines from pyPgSQL/libpq/__init__.py - from libpq import * from libpq import __version__ HAVE_LONG_LONG_SUPPORT = dir().count('PgInt8') == 1 #-------------------------------------------------- -------------+ # Add support to pickle the following pyPgSQL objects: | # PgInt2, PgInt8, PgBoolean | #-------------------------------------------------- -------------+ def _B(value): return PgBoolean(value) def _I2(value): return PgInt2(value) def _I8(value): return PgInt8(value) Somehow pyPgSQL is responding to my unpickling command, and raising an error because PgInt8 is not defined. Here is another fact, which may provide a clue or may add confusion. If I run exactly the same program from the Linux box, using it as the client as well as the server, the error does not appear. I connect via the external IP address, not via 127.0.0.1, so I would have thought it would behave the same, but it does not. ------------------------------------------------------ ------------------------- Ok, here is the reason. I mentioned above that a typical tuple consists of (2,'Ar',17,1). I have found that under some circumstances the 3rd element is of type 'long' instead of type 'int', and this is what generates the error. Whether it is a long or an int is determined by pyPgSQL itself. It is a column value, where the column is of type 'serial', which means that PostgreSQL will generate a next number if the row is being inserted. If the row exists, the column value is returned along with all the other columns, and is returned as type int. If the row does not exist, I insert it, and then to retrieve the id generated, I have the following piece of code - cur = db.cursor() cur.execute("select currval('%s_%s_Seq')" % (tableid,columnid) ) rowid = cur.fetchone()[0] In this case, rowid contains the correct value, but is of type long. So this raises various questions - Why is PgInt8 not defined? Why does pyPgSQL affect my server program, which does not import any of pyPgSQL? Why does the error only occur when I connect from a remote machine? Now that I have identified the problem, I can work around it, so this has become a matter of correctness rather than a matter of urgency. Frank Millman ---------------------------------------------------------------------- >Comment By: Frank Millman (frankmillman) Date: 2004-08-09 09:29 Message: Logged In: YES user_id=1070042 Apologies - my diagnosis was not quite correct. What is actually happening is as follows. Refer to the lines where I retrieve the id generated, ending with "rowid = cur.fetchone()[0]" If this line is executed from a Linux machine, rowid's type is "long". If it is executed from a Windows machine, rowid's type is "PgInt8". This explains why the error only occurs when I connect from the Windows machine. Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-07 07:26:03
|
Bugs item #1005037, was opened at 2004-08-07 07:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with pgInt8 not defined Initial Comment: This is a copy of a message sent to comp.lang.python regarding a possible bug in pgPySQL. It is rather long, but I have reproduced it verbatim as any/all of it may be significant. Thanks. Below is the text of a message I was about to send in connection with an obscure problem. I have now almost got to the bottom of it, and am fairly confident that it is a bug in pyPgSQL. I hope this is the correct place to report such bugs. If not, please advise the correct forum. I have left the original message intact as it provides important information. At the bottom, I have recorded the new information that I have discovered. ------------------------------------------------------ ------------------------- Here is an obscure problem. I am not sure if I can explain the symptoms properly, but I will do my best. I have a Linux box (RH9) and an MSW box (W2K Pro) networked to each other. Both are running Python 2.3.3. Linux is the server. It is running PostgreSQL, which listens on port 5432. It is also running a socket server program that I have written using socket.socket(), listening on port 6543. I am using pyPgSQL to connect to the database. MSW is the client. From time to time it sends messages to my socket server. Messages are strings consisting of a single digit identifier, followed by a cPickle'd tuple containing various data fields. The client uses cPickle.dumps to prepare the string before sending, and the server uses cPickle.loads to unpickle it after receiving. Most times it works perfectly, but in one particular situation the server terminates with an error. The error is consistent - it always gives the same error resulting from the same message. However, I do not think it is caused by the message itself, as exactly the same message is sent in different circumstances without generating an error. The traceback is as follows - File "./chag_server.py", line 190, in ? dat = cPickle.loads(data[1:]) File "/usr/local/lib/python2.3/site- packages/pyPgSQL/libpq/__init__.py", line 43, in _I8 return PgInt8(value) NameError: ("global name 'PgInt8' is not defined", <function _I8 at 0x403a04c4>, ('17',)) The error occurs at the point of unpickling - I have moved this around, and it always fails at this point. A typical example of the tuple being unpickled is (2,'Ar',17,1) - it is all normal strings and integers. I have no idea why pyPgSQL is involved at all - I am certainly not invoking it directly. In fact the error comes from my server program, and that does not even import pyPgSQL. Here are the relevant lines from pyPgSQL/libpq/__init__.py - from libpq import * from libpq import __version__ HAVE_LONG_LONG_SUPPORT = dir().count('PgInt8') == 1 #-------------------------------------------------- -------------+ # Add support to pickle the following pyPgSQL objects: | # PgInt2, PgInt8, PgBoolean | #-------------------------------------------------- -------------+ def _B(value): return PgBoolean(value) def _I2(value): return PgInt2(value) def _I8(value): return PgInt8(value) Somehow pyPgSQL is responding to my unpickling command, and raising an error because PgInt8 is not defined. Here is another fact, which may provide a clue or may add confusion. If I run exactly the same program from the Linux box, using it as the client as well as the server, the error does not appear. I connect via the external IP address, not via 127.0.0.1, so I would have thought it would behave the same, but it does not. ------------------------------------------------------ ------------------------- Ok, here is the reason. I mentioned above that a typical tuple consists of (2,'Ar',17,1). I have found that under some circumstances the 3rd element is of type 'long' instead of type 'int', and this is what generates the error. Whether it is a long or an int is determined by pyPgSQL itself. It is a column value, where the column is of type 'serial', which means that PostgreSQL will generate a next number if the row is being inserted. If the row exists, the column value is returned along with all the other columns, and is returned as type int. If the row does not exist, I insert it, and then to retrieve the id generated, I have the following piece of code - cur = db.cursor() cur.execute("select currval('%s_%s_Seq')" % (tableid,columnid) ) rowid = cur.fetchone()[0] In this case, rowid contains the correct value, but is of type long. So this raises various questions - Why is PgInt8 not defined? Why does pyPgSQL affect my server program, which does not import any of pyPgSQL? Why does the error only occur when I connect from a remote machine? Now that I have identified the problem, I can work around it, so this has become a matter of correctness rather than a matter of urgency. Frank Millman ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-03 22:17:29
|
in pgnotify.c Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Bugs item #1001593, was opened at 2004-08-01 14:46 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001593&group_id=16528 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Billy G. Allie (ballie01) >Summary: Bad free() in pgnotify.c Initial Comment: pgnotify.c 1.8 contains `free(note);', but there is no malloc(), calloc() etc anywhere in pypgsql. I don't know how pgnotify is used, but I imagine PyMalloc will break this, and the free() should be PyMem_Free(), PyObject_Free() or PyObject_Del(). ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-08-03 18:17 Message: Logged In: YES user_id=8500 No, the free() is valid. The PgNotify_New() function is passed a structure allocated by PostgreSQL's libpq library and needs to be freed after use. PostgreSQL added a PQfreemem() function for compatability with windows, so I will modify the code to use PQfreemem (which is just a call to free() in the linux/unix workd) instead of free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001593&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-03 18:32:01
|
Patches item #1002802, was opened at 2004-08-03 20:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1002802&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: libpqmodule spelling fix Initial Comment: The attached patch contains some trivial spelling fixes ( s/requireed/ required/g ) which we have in pkgsrc for a long time now. They are originally from FreeBSD ports, IIRC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1002802&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-02 23:16:55
|
Bugs item #1002323, was opened at 2004-08-03 01:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1002323&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong scale/prec tests in PgNumeric Initial Comment: PgSQL.py 1.43: PgNumeric.__init__(self, PgNumeric instance, ...) has a test if scale: which means a specified scale of 0 will be ignored. I think that should be if scale is not None: The same applies to the 'if prec:' test further down, but that's less serious since prec may not be 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1002323&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-02 06:23:56
|
Bugs item #967375, was opened at 2004-06-06 11:04 Message generated for change (Comment added) made by bab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Gerhard Häring (ghaering) Summary: Incomplete utf-8 support Initial Comment: Hi. Again from the debian BTS (#232217). - Ben. I just found this: /usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py in execute(self=<pyPgSQL.PgSQL.Cursor instance>, query='INSERT INTO sessiondata (session,object,key,valu...UES (%(param1)s,%(param2)s,%(param3)s,%(param4)s)', *parms={'param1': "'00E003088E7A'", 'param2': "'userinfo'", 'param3': "'surname'", 'param4': "'Hj\xf0\xae\xae\xa5v\xe5\xa7\xa2 type='"}) 3070 self.conn.__dict__["inTransaction"] = 0 3071 self.conn._Connection__closeCursors() 3072 raise OperationalError, msg 3073 except InternalError, msg: 3074 # An internal error occured. Try to get to a sane state. global OperationalError = <class libpq.OperationalError> msg = <libpq.OperationalError instance> OperationalError: ERROR: Unicode >= 0x10000 is not supported which seems to say that PgSQL only supports a subset of the unicode character set. This is a bit of a problem for us since we have customers using those (which is how I got that backtrace). ---------------------------------------------------------------------- >Comment By: Ben Burton (bab) Date: 2004-08-02 16:23 Message: Logged In: YES user_id=146613 Ah, you're quite right. From the postgresql sources: postgresql-7.4.3/src/backend/utils/mb/wchar.c, pg_verifymbstr(): /* special UTF-8 check */ if (encoding == PG_UTF8 && (*mbstr & 0xf8) == 0xf0) { if (noError) return false; ereport(ERROR, (errcode(ERRCODE_CHARACTER_NOT_IN_REPERTOIRE), errmsg("Unicode characters greater than or equal to 0x10000 are not supported"))); } I'm therefore closing this bug (and I've reassigned the corresponding debian bug to postgresql). ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2004-08-01 06:32 Message: Logged In: YES user_id=8500 This sounds like the error is coming from PostgreSQL and that PostgreSQL could not handle the Unicode value. Have you tried sending the query directly to the database using psql? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-08-01 18:46:57
|
in pgnotify.c Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Bugs item #1001593, was opened at 2004-08-01 20:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001593&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: Bad free() in pgnotify.c Initial Comment: pgnotify.c 1.8 contains `free(note);', but there is no malloc(), calloc() etc anywhere in pypgsql. I don't know how pgnotify is used, but I imagine PyMalloc will break this, and the free() should be PyMem_Free(), PyObject_Free() or PyObject_Del(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001593&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 20:32:49
|
Bugs item #967375, was opened at 2004-06-05 21:04 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) >Assigned to: Gerhard Häring (ghaering) Summary: Incomplete utf-8 support Initial Comment: Hi. Again from the debian BTS (#232217). - Ben. I just found this: /usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py in execute(self=<pyPgSQL.PgSQL.Cursor instance>, query='INSERT INTO sessiondata (session,object,key,valu...UES (%(param1)s,%(param2)s,%(param3)s,%(param4)s)', *parms={'param1': "'00E003088E7A'", 'param2': "'userinfo'", 'param3': "'surname'", 'param4': "'Hj\xf0\xae\xae\xa5v\xe5\xa7\xa2 type='"}) 3070 self.conn.__dict__["inTransaction"] = 0 3071 self.conn._Connection__closeCursors() 3072 raise OperationalError, msg 3073 except InternalError, msg: 3074 # An internal error occured. Try to get to a sane state. global OperationalError = <class libpq.OperationalError> msg = <libpq.OperationalError instance> OperationalError: ERROR: Unicode >= 0x10000 is not supported which seems to say that PgSQL only supports a subset of the unicode character set. This is a bit of a problem for us since we have customers using those (which is how I got that backtrace). ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:32 Message: Logged In: YES user_id=8500 This sounds like the error is coming from PostgreSQL and that PostgreSQL could not handle the Unicode value. Have you tried sending the query directly to the database using psql? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 20:32:20
|
Bugs item #967375, was opened at 2004-06-05 21:04 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete utf-8 support Initial Comment: Hi. Again from the debian BTS (#232217). - Ben. I just found this: /usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py in execute(self=<pyPgSQL.PgSQL.Cursor instance>, query='INSERT INTO sessiondata (session,object,key,valu...UES (%(param1)s,%(param2)s,%(param3)s,%(param4)s)', *parms={'param1': "'00E003088E7A'", 'param2': "'userinfo'", 'param3': "'surname'", 'param4': "'Hj\xf0\xae\xae\xa5v\xe5\xa7\xa2 type='"}) 3070 self.conn.__dict__["inTransaction"] = 0 3071 self.conn._Connection__closeCursors() 3072 raise OperationalError, msg 3073 except InternalError, msg: 3074 # An internal error occured. Try to get to a sane state. global OperationalError = <class libpq.OperationalError> msg = <libpq.OperationalError instance> OperationalError: ERROR: Unicode >= 0x10000 is not supported which seems to say that PgSQL only supports a subset of the unicode character set. This is a bit of a problem for us since we have customers using those (which is how I got that backtrace). ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:32 Message: Logged In: YES user_id=8500 This sounds like the error is coming from PostgreSQL and that PostgreSQL could not handle the Unicode value. Have you tried sending the query directly to the database using psql? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=967375&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 20:27:26
|
Bugs item #1001242, was opened at 2004-07-31 13:57 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 Category: PgSQL Group: None >Status: Pending Resolution: Fixed Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Billy G. Allie (ballie01) Summary: typecast typo: __comm should be __conn Initial Comment: There is a typo in the bugfix to typecast() in PgSQL.py rev 1.40: 'self.conn' was "fixed" to 'self.__comm.conn'. It should be 'self.__conn.conn' as in handleArray(). ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:21 Message: Logged In: YES user_id=8500 It's fixed and committed to CVS. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:21 Message: Logged In: YES user_id=8500 It's fixed and committed to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 20:26:59
|
Bugs item #1001178, was opened at 2004-07-31 09:49 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001178&group_id=16528 Category: Documentation Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: William Robinson (airbaggins) Assigned to: Nobody/Anonymous (nobody) Summary: PgTrue/PgFalse in README instead of PG_True/PG_False Initial Comment: The constants for PgBooleans are documented as being PgTrue/PgFalse in the main README documentation instead of PG_True/PG_False. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:26 Message: Logged In: YES user_id=8500 It's been changed and commited to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001178&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 20:21:28
|
Bugs item #1001242, was opened at 2004-07-31 13:57 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Billy G. Allie (ballie01) Summary: typecast typo: __comm should be __conn Initial Comment: There is a typo in the bugfix to typecast() in PgSQL.py rev 1.40: 'self.conn' was "fixed" to 'self.__comm.conn'. It should be 'self.__conn.conn' as in handleArray(). ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:21 Message: Logged In: YES user_id=8500 It's fixed and committed to CVS. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:21 Message: Logged In: YES user_id=8500 It's fixed and committed to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 20:21:09
|
Bugs item #1001242, was opened at 2004-07-31 13:57 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 Category: PgSQL Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Billy G. Allie (ballie01) Summary: typecast typo: __comm should be __conn Initial Comment: There is a typo in the bugfix to typecast() in PgSQL.py rev 1.40: 'self.conn' was "fixed" to 'self.__comm.conn'. It should be 'self.__conn.conn' as in handleArray(). ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2004-07-31 16:21 Message: Logged In: YES user_id=8500 It's fixed and committed to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 17:57:31
|
Bugs item #1001242, was opened at 2004-07-31 19:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: typecast typo: __comm should be __conn Initial Comment: There is a typo in the bugfix to typecast() in PgSQL.py rev 1.40: 'self.conn' was "fixed" to 'self.__comm.conn'. It should be 'self.__conn.conn' as in handleArray(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001242&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-31 13:50:00
|
Bugs item #1001178, was opened at 2004-07-31 13:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001178&group_id=16528 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: William Robinson (airbaggins) Assigned to: Nobody/Anonymous (nobody) Summary: PgTrue/PgFalse in README instead of PG_True/PG_False Initial Comment: The constants for PgBooleans are documented as being PgTrue/PgFalse in the main README documentation instead of PG_True/PG_False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1001178&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-07-23 10:18:30
|
Patches item #996442, was opened at 2004-07-23 12:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=996442&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Nobody/Anonymous (nobody) Summary: PgSQL.Cursor.__fetchManyRows shoud use xrange Initial Comment: In PgSQL.Cursor.__fetchManyRows range(count) may generate a huge list, if a large count is used. (This happens in combination with ZpyPgSQLDA.db.DB.query with no max_rows set (Its default is 9999999!)) Maybe using xrange can help, it speeds things daratically up. (see also http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-73 ) So I attached a patch to use xrange instead of range. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=996442&group_id=16528 |
1 message has been excluded from this view by a project administrator.
