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...> - 2006-06-25 10:14:09
|
Patches item #1511984, was opened at 2006-06-25 03:34 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1511984&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Clarence (clarence1126) >Assigned to: Billy G. Allie (ballie01) Summary: Add savepoint method to Connection Initial Comment: Adds savepoint() and release() methods to Connection, and modifies rollback() to optionally rollback only to the savepoint. Deals only with one, unnamed from the user's point of view, savepoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1511984&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-25 01:34:10
|
Patches item #1511984, was opened at 2006-06-24 18:34 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=1511984&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Clarence (clarence1126) Assigned to: Nobody/Anonymous (nobody) Summary: Add savepoint method to Connection Initial Comment: Adds savepoint() and release() methods to Connection, and modifies rollback() to optionally rollback only to the savepoint. Deals only with one, unnamed from the user's point of view, savepoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1511984&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-22 09:40:58
|
Bugs item #800801, was opened at 2003-09-05 02:17 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=800801&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: PgSQL Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) >Assigned to: Gerhard Häring (ghaering) Summary: Precision lost from mxDateTime during queries Initial Comment: When working with PostgreSQL timestamps, round-trips to/from Python wind up losing data (the least-significant digits of the timestamp, 1000ths of seconds and less). Result is that timestamps which include 1000ths of seconds cannot be queried from Python using mxDateTime values. PyPgSQL should likely be using code something like the following to format an mxDateTime value for a timestamp: new.Format( '%Y-%m-%d %H:%M:%%s' )%( new.second, ) or new.Format( '%Y-%m-%d %H:%M:%%r' )%( new.second, ) (difference being use of 'r' format, which will do as much as possible to be sure that the resulting string is capable of exactly producing the original format). To illustrate: from pytable import dbspecifier, sqlquery spec = dbspecifier.DBSpecifier( dbdriver='PyPgSQL', database='cinemon', host='localhost', user='cinemon', password='xxxx' ) driver, connection = spec.connect() ((new,),) = sqlquery.SQLQuery( sql = """SELECT MAX( archive_ts ) from log_modem;""" )( connection ) print 'new', repr(new) print 'seconds', new.second records = sqlquery.SQLQuery( sql = """SELECT * from log_modem where archive_ts = %%(new)s;""" )( connection, new=new ).fetchall() print records # is an empty list because of truncation... V:\cinemon>err_date_truncation.py new <DateTime object for '2003-09-04 19:50:16.30' at 93a820> seconds 16.297984 [] ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-22 11:40 Message: Logged In: YES user_id=163326 Thanks. I'll try to integrate your proposal for 2.5.2. Sigh. Better late than never. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=800801&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-09 22:33:22
|
Feature Requests item #1503756, was opened at 2006-06-09 15:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=366528&aid=1503756&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Clarence (clarence1126) Assigned to: Nobody/Anonymous (nobody) Summary: SAVEPOINT needs to be done through a Connection method Initial Comment: My application has the following outline: 1) Delete all data for a given hour 2) Do many inserts to update the data for that hour Any of those inserts might fail due to referential integrity violations, and that is acceptable. However, any such error invalidates the transaction. The current code actually does 1) Delete all data for a given hour 1a) Commit 2) Insert new data (1 tuple) for the hour 2a) Commit 2c) go to 2 This of course causes the data for that hour to be read as either zero or any value up to the the correct value. So I want to use savepoints instead. But I cannot use them through a cursor, for the same reason that one cannot do commits/rollbacks through a cursor, namely that the Connection object wants to know about the state, hence it provides the commit and rollback methods. The Connection object needs to know about savepoints because currently, if any query gets an error, the Connection object issues a ROLLBACK. If the user has previously set a savepoint via a query, the Connection doesn't know that and the user's work is not saved. So I would suggest some kind of savepoint access be added to the Connection. I don't think it necessarily needs to be as baroque as allowed by the SQL standard, in particular multiple savepoints outstanding, etc. In fact, I'll probably make a local modification which will consist of just a savepoint() and release() method, taking no arguments, just to get my problem solved. More than that may not be necessary (given that nobody has apparently ever even run into the problem before). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=366528&aid=1503756&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-07 17:35:58
|
Bugs item #1501951, was opened at 2006-06-07 02:59 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libpq Group: None >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Ben Burton (bab) Assigned to: Gerhard Häring (ghaering) Summary: Insecure quote escaping [CVE-2006-2314] Initial Comment: Hi, There was a recent security hole in PostgreSQL involving the escaping of quotes (\' vs ''). It is a little unfortunate that the relevant pypgsql patch came out around the same time as your 2.5 release (and therefore didn't make the release); anyway, the patch is included here. >From the original debian bug report (#369250): Recently, a security hole has been discovered in PostgreSQL client applications, see http://www.postgresql.org/docs/techdocs.50 for details. In short, using \' for quote escaping is insecure and now not allowed any more in some encodings which are prone to this SQL injection attack. Quotes in python-pgsql are escaped with \'. The attached patch fixes that to use '' instead. Thanks to Martin Pitt for the patch. The relevant CVE number is CVE-2006-2314. Ben. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-07 19:35 Message: Logged In: YES user_id=163326 Fixed in 2.5.1 just released. Thanks! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2006-06-07 19:11 Message: Logged In: YES user_id=163326 Thanks a lot for the patch. Expect a pyPgSQL 2.5.1 release very soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-07 17:11:18
|
Bugs item #1501951, was opened at 2006-06-07 02:59 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libpq Group: None Status: Open Resolution: None Priority: 9 Submitted By: Ben Burton (bab) >Assigned to: Gerhard Häring (ghaering) Summary: Insecure quote escaping [CVE-2006-2314] Initial Comment: Hi, There was a recent security hole in PostgreSQL involving the escaping of quotes (\' vs ''). It is a little unfortunate that the relevant pypgsql patch came out around the same time as your 2.5 release (and therefore didn't make the release); anyway, the patch is included here. >From the original debian bug report (#369250): Recently, a security hole has been discovered in PostgreSQL client applications, see http://www.postgresql.org/docs/techdocs.50 for details. In short, using \' for quote escaping is insecure and now not allowed any more in some encodings which are prone to this SQL injection attack. Quotes in python-pgsql are escaped with \'. The attached patch fixes that to use '' instead. Thanks to Martin Pitt for the patch. The relevant CVE number is CVE-2006-2314. Ben. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-07 19:11 Message: Logged In: YES user_id=163326 Thanks a lot for the patch. Expect a pyPgSQL 2.5.1 release very soon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-07 01:00:35
|
Bugs item #1501951, was opened at 2006-06-07 10:59 Message generated for change (Settings changed) made by bab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libpq Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: Insecure quote escaping [CVE-2006-2314] Initial Comment: Hi, There was a recent security hole in PostgreSQL involving the escaping of quotes (\' vs ''). It is a little unfortunate that the relevant pypgsql patch came out around the same time as your 2.5 release (and therefore didn't make the release); anyway, the patch is included here. >From the original debian bug report (#369250): Recently, a security hole has been discovered in PostgreSQL client applications, see http://www.postgresql.org/docs/techdocs.50 for details. In short, using \' for quote escaping is insecure and now not allowed any more in some encodings which are prone to this SQL injection attack. Quotes in python-pgsql are escaped with \'. The attached patch fixes that to use '' instead. Thanks to Martin Pitt for the patch. The relevant CVE number is CVE-2006-2314. Ben. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-07 00:59:13
|
Bugs item #1501951, was opened at 2006-06-07 10:59 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=1501951&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: Insecure quote escaping [CVE-2006-2314] Initial Comment: Hi, There was a recent security hole in PostgreSQL involving the escaping of quotes (\' vs ''). It is a little unfortunate that the relevant pypgsql patch came out around the same time as your 2.5 release (and therefore didn't make the release); anyway, the patch is included here. >From the original debian bug report (#369250): Recently, a security hole has been discovered in PostgreSQL client applications, see http://www.postgresql.org/docs/techdocs.50 for details. In short, using \' for quote escaping is insecure and now not allowed any more in some encodings which are prone to this SQL injection attack. Quotes in python-pgsql are escaped with \'. The attached patch fixes that to use '' instead. Thanks to Martin Pitt for the patch. The relevant CVE number is CVE-2006-2314. Ben. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1501951&group_id=16528 |
|
From: Tim W. <twe...@ra...> - 2006-06-05 02:12:24
|
Hi, After upgrading to pyPgSQL 2.5 (from 2.4) the returned DateTime objects returned from querying timestamp fields return different dates (for the same record). 2.4 result: <DateTime object for '2006-05-29 08:09:11.00' at b7c85758> 2.5 result: <DateTime object for '2006-05-29 17:39:11.00' at b7f91d08> psql interactive result: 2006-05-29 08:09:11 Note that it adds exactly 9 hours and 30 minutes (I've tested this with various queries and it consistently does this). My timezone is +9:30. System details: Fedora Core 3 Linux postgresql-7.4.8-1.FC3.1 python-2.3.4-13.1 Is this a bug or are timezones handles differently in 2.5? Regards, Tim |
|
From: SourceForge.net <no...@so...> - 2006-06-02 14:55:08
|
Bugs item #1325835, was opened at 2005-10-13 15:57 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1325835&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Billy G. Allie (ballie01) Summary: PyPGSQl crashes Python on specific dates Initial Comment: cs=cn.cursor() cs.execute("select '1932-01-01 00:00'::timestamp") cs.fetchone() leads to a total crash of Python ("invalid memory access"), not a mere exception, but a hard crash. to reproduce: cn must be a conneciton ... Harald ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 16:55 Message: Logged In: YES user_id=163326 It cannot work with the current implementation. The crash really happens in mxDateTime, you can provoke it using: import mx.DateTime as dt print dt.Parser.DateTimeFromString("1932-01-01 00:00").localtime() You should be able to make mxDateTime and thus pyPgSQL not crash by setting the module-level variable in PgSQL to 1: from pyPgSQL import PgSQL PgSQL.useUTCtimeValue = 1 ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2005-10-14 11:51 Message: Logged In: YES user_id=665785 updating my bad bugreport.. sorry for not being more precise in the first run. I use pyPgSQL-pre2.5-20050926.win32-py2.4.exe as PyPgSQL. Python is 2.4.1 (#65, Mar 30 2005) and also tested (same problem) Python 2.4.2 (#67, Sep 28 2005, 12:41:11) (both from python.org) libpq.dll is: PostgreSQL 8.1-beta3, installed from the installer libpq.dll from 12.10.2005 11:39 with 169.145 bytes mx.DateTime is Version 2.0.3 and also testet (same problem) Version 2.0.6 (all on win32, XP SP2) (and adding: yes, of course I do a select on a normal table where the timestamps do reside; NOT that I just cast a constant to crash Python :) ) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2005-10-14 07:04 Message: Logged In: YES user_id=8500 I'm not able to reproduce the error: >>> cn = PgSQL.connect(database='issueLog', password='********) >>> cur = cn.cursor() >>> cur.execute("select '1932-01-01 00:00'::timestamp") >>> res = cur.fetchone() >>> res [<DateTime object for '1932-01-01 00:00:00.00' at b7c58ec8>] >>> What version of Python / PostgreSQL / mxDateTime are you using? ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2005-10-13 16:07 Message: Logged In: YES user_id=665785 additional information: its with the september 2005 version (interim) workaround: use to_char(datefield,'YYYY-MM-DD HH24:MI:SS') instead of datefield in your selects ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1325835&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 14:28:40
|
Bugs item #882032, was opened at 2004-01-22 11:22 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libpq Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Billy G. Allie (ballie01) Summary: Wrong PG_Version check for dbExperts PostgreSQL Initial Comment: We have dbExperts PostgreSQL (a native Postgres for Windows). The dbExperts people add a -dbexperts to the VersionString (after the Version number). This makes pgversion.c upset. We are using pypgsql version 2.4 Attached is a patch to fix this issue. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 16:28 Message: Logged In: YES user_id=163326 Thanks for the patch. I applied it to CVS and adjusted the test suite accordingly. ---------------------------------------------------------------------- Comment By: Rune Frøysa (runefro) Date: 2004-05-13 13:27 Message: Logged In: YES user_id=604567 This problem also affects rh-postgresql-server-7.3.6-1 from redhat. With the patch, the only error from test/PgSQLTestCases.py is: FAIL: CheckPgVer (__main__.PgSQLTestCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/PgSQLTestCases.py", line 591, in CheckPgVer self.fail(msg) File "/usr/lib/python2.2/unittest.py", line 254, in fail raise self.failureException, msg AssertionError: SELECT version() says 7.3.6-RH, cnx.version says 7.3.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=882032&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 14:11:01
|
Bugs item #1327846, was opened at 2005-10-16 11:48 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1327846&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Randy Kaelber (randyk) Assigned to: Nobody/Anonymous (nobody) Summary: More unexpected version checks Initial Comment: The version of PostgreSQL that I checked out of CVS reports its minor version as xbetay, instead of xby. This of course, makes the version string parser barf as per previous bugs. I have included a simple patch to deal with the new version string, but is it really the right thing to throw an exception making a connection because we can't parse the version string as well as we'd like to? I will work up a more involved patch in the near future to maybe display some sort of warning, but it's pretty annoying to not even be able to connect to my database because the server decides to toss us a weird version string. I also fixed the typo of "Ivalid". :-) ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 16:10 Message: Logged In: YES user_id=163326 Was fixed by bga in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1327846&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:55:22
|
Bugs item #1409818, was opened at 2006-01-19 12:03 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1409818&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Problem using SAVEPOINT Initial Comment: We are using PostgreSQL 8.1.1 with pyPgSQL-2.4.win32-py2.3.exe. Executing the following code in e.g. pgadmin works as expected: SAVEPOINT APS_SAVEPOINT2; SELECT persons.oid FROM persons WHERE person_id = '9'; ROLLBACK TO APS_SAVEPOINT2; SELECT persons.oid FROM persons WHERE person_id = '9' Executing the code inside of the python interface to PostgreSQL using: from pyPgSQL import PgSQL connection = PgSQL.connect(...) cursor=connection.cursor() cursor.execute("SAVEPOINT APS_SAVEPOINT2") cursor.execute("SELECT persons.oid FROM persons WHERE person_id = '9'") cursor.execute("ROLLBACK TRANSACTION TO SAVEPOINT APS_SAVEPOINT2") cursor.execute("SAVEPOINT APS_SAVEPOINT3") cursor.execute("SELECT persons.oid FROM persons WHERE person_id = '9'") does not work. An exception is raised: libpq.OperationalError: ERROR: current transaction is aborted, commands ignored until end of transaction block I can't see the reason. But I think it lies somewhere in libpq. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:55 Message: Logged In: YES user_id=163326 I believe it has to do with portals. If you close the cursor and create a new one before the "ROLLBACK TRANSACTION", you don't get this error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1409818&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:47:58
|
Bugs item #1224276, was opened at 2005-06-20 18:28 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1224276&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: Please use pg_config to find include dirs in setup.py Initial Comment: Hi again, Debian has recently moved its postgresql include directories around (to allow for side-by-side installations of postgresql 7.4 and 8.0). As a result, pypgsql no longer builds out of the box. A failsafe method of fixing problems like this is to use "pg_config --includedir" in setup.py for deciding on the C include directories, instead of using the current hard-coded list of /usr/include, /usr/include/postgresql and /usr/include/pgsql . The patch is fairly simple; I've included it as an attachment to this bug report. Thanks - Ben. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:47 Message: Logged In: YES user_id=163326 pg_config is now used on all platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1224276&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:37:15
|
Bugs item #1016005, was opened at 2004-08-25 16:20 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016005&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None >Status: Closed >Resolution: Fixed 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) ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:37 Message: Logged In: YES user_id=163326 Unicode is supported now and ARRAYs are supported via PgSQL.PgArray. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016005&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:33:50
|
Bugs item #760412, was opened at 2003-06-25 13:23 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=760412&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Ian (ian888) Assigned to: Billy G. Allie (ballie01) Summary: array.py regression test fails version 2.3, linux Initial Comment: ia...@fo... Using Postgress 7.3.3 and pypgsql version 2.3, I built pypgsql on SuSE 8.2 linux. All tests Passed except this one. This could be a test failure as opposed to be a real failure. Please investigate. text follows: carra:/usr/share/pypgsql/test/regression # python array.py ....E ====================================================================== ERROR: CheckForIntInsertMultiDim (__main__.ArrayTestCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "array.py", line 181, in CheckForIntInsertMultiDim cursor.execute("insert into test(ia) values (%s)", intlist) File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2956, in execute raise OperationalError, msg OperationalError: ERROR: pg_atoi: zero-length string ---------------------------------------------------------------------- Ran 5 tests in 7.217s FAILED (errors=1) carra:/usr/share/pypgsql/test/regression # ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:33 Message: Logged In: YES user_id=163326 This whole array thing should be looked into again, but for now, closing is out of date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=760412&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:31:17
|
Bugs item #1016010, was opened at 2004-08-25 16:25 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016010&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgResult Group: None >Status: Closed Resolution: Fixed 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 ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2005-02-27 19:41 Message: Logged In: YES user_id=163326 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1016010&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:30:53
|
Bugs item #1103260, was opened at 2005-01-16 09:57 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1103260&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgInt2 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: comparison with float fails on Python 2.4 Initial Comment: Running the regression test of pyPgSQL 2.4 on a build for Python 2.4 has 2 failures: ...............FF................................................. ====================================================================== FAIL: CheckPgInt2 (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 216, in CheckPgInt2 self.failUnless(a == 181.0, 'PgInt2 comparison to Float failed.') AssertionError: PgInt2 comparison to Float failed. ====================================================================== FAIL: CheckPgInt8 (__main__.PgSQLTestModuleInterface) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 184, in CheckPgInt8 'PgInt8 comparison to Float failed.') AssertionError: PgInt8 comparison to Float failed. ---------------------------------------------------------------------- Ran 66 tests in 36.950s FAILED (failures=2) The regression test has no failures when built with Python 2.3.4. This is on OS/2 EMX - I can't test this on another platform at the moment :-( I have done some debugging, and the issue appears to arise from the int2_coerce()/int8_coerce() functions. I have been able to modify these functions to get these tests to pass, but then the ability to add other number types with PgInt2/PgInt8 objects fails.... For what its worth, I've attached the patch I came up with for reference purposes (I don't believe its suitable for application to the source tree). This patch is based on behaviour I inferred from the way that the Python native numeric types have their coercion routines written. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:30 Message: Logged In: YES user_id=163326 Andrew, thanks a lot for the patch. In the meantime I fixed the problem by getting rid of the usage of PgInt2/PgInt8 altogether. I'll try to remember your patch and maybe look at this at a later point. The comparison problem with float is fixed now by just switch to int/long instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1103260&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:28:15
|
Bugs item #1187803, was opened at 2005-04-22 04:15 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1187803&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Wegener (twegener) Assigned to: Nobody/Anonymous (nobody) Summary: 2 regression tests fail on Fedora Core 3 (python 2.3.4) Initial Comment: Here are the system setup details: Fedora Core 3 Linux (i386/i686) $ rpm -q postgresql postgresql-7.4.7-3.FC3.1 $ rpm -q python python-2.3.4-13.1 $ rpm -q pyPgSQL # Home built RPM using spec from tarball pyPgSQL-2.4-FC3_py2.3 Here is the output generated by 'PgSQLTestCases.py': $ python PgSQLTestCases.py .................../usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py:2644: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up name = "PgSQL_%08X" % id(self) .....................F.F....................... ====================================================================== FAIL: CheckDoMoreResultObjectChecks (__main__.PgSQLTestCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 817, in CheckDoMoreResultObjectChecks self.fail(msg) File "/usr/lib/python2.3/unittest.py", line 270, in fail raise self.failureException, msg AssertionError: '7.4' ====================================================================== FAIL: Test execute() with a singleton string as the parameter. ---------------------------------------------------------------------- Traceback (most recent call last): File "PgSQLTestCases.py", line 639, in CheckExecuteWithSingleton "Length of cur.description is %d, it should be %d." % File "/usr/lib/python2.3/unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: Length of cur.description is 11, it should be 4. ---------------------------------------------------------------------- Ran 66 tests in 0.740s FAILED (failures=2) ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:28 Message: Logged In: YES user_id=163326 Everything was fixed so that all tests pass without warnings now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1187803&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:20:22
|
Bugs item #1036908, was opened at 2004-09-29 12:08 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1036908&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: rangzen (rangzen) Assigned to: Gerhard Häring (ghaering) Summary: A long, long setup.py build Initial Comment: Hello, In setup.py : # XXX: This is an ugly hack to make bdist_rpm find the include files. include_dirs.append("../" * 5) If you have an autofs system in /net for example, the build part try to find /net/time.h, /net/xyz.h, etc. None of my computer has those name ;p If you don't comment "include_dirs.append("../" * 5)" in setup.py, the build wait for each file ... It's a very long build :) Thx ! ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:20 Message: Logged In: YES user_id=163326 Workaround for RPM removed in CVS. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2004-10-05 10:09 Message: Logged In: YES user_id=163326 If there's an alternative way to make the RPM build work, I'll be happy to remove this ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1036908&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:19:39
|
Bugs item #1186055, was opened at 2005-04-19 17:34 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1186055&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgConnection Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Nobody/Anonymous (nobody) Summary: debugQuery does not build in win32 Initial Comment: debugQuery uses strcasecmp which win32 (MSVC++ 6.0) does not have. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:19 Message: Logged In: YES user_id=163326 Current CVS compiles fine on win32 with MSVC6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1186055&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-06-02 13:02:10
|
Bugs item #1005037, was opened at 2004-08-07 09:26 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1005037&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed 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: Gerhard Häring (ghaering) Date: 2006-06-02 15:02 Message: Logged In: YES user_id=163326 pyPgSQL 2.5 does not use the PgInt2 or PgInt8 extension types any longer, so this problem cannot occur any more. ---------------------------------------------------------------------- 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...> - 2006-06-02 13:01:00
|
Bugs item #654957, was opened at 2002-12-17 02:43 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=654957&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Gerhard Häring (ghaering) Assigned to: Billy G. Allie (ballie01) Summary: How to run test suite? Initial Comment: A MacOS X user whom I was assisting getting pyPgSQL 2.3 to work on his machine was telling me that the instructions in the README about running the test suite don't work for him. In fact, they can't work because "python test/PgSQLTestCases.py" won't work if you built pyPgSQL with "... setup.py build" before. I personally just copy the test directory with a "cp -r ..." to build/lib.{platform}" but I wonder what you do during development? There's the possibility to use a "python setup.py build --build-lib ." instead, with which the instructions in README would work. I personally don't do this because it clutters up my pyPgSQL sandbox. If you know how to change the instructions, could you please do so? Thanks. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-06-02 15:00 Message: Logged In: YES user_id=163326 Deferred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=654957&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-05-28 22:30:54
|
Bugs item #1036908, was opened at 2004-09-29 12:08 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1036908&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: None >Priority: 1 Submitted By: rangzen (rangzen) >Assigned to: Gerhard Häring (ghaering) Summary: A long, long setup.py build Initial Comment: Hello, In setup.py : # XXX: This is an ugly hack to make bdist_rpm find the include files. include_dirs.append("../" * 5) If you have an autofs system in /net for example, the build part try to find /net/time.h, /net/xyz.h, etc. None of my computer has those name ;p If you don't comment "include_dirs.append("../" * 5)" in setup.py, the build wait for each file ... It's a very long build :) Thx ! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2004-10-05 10:09 Message: Logged In: YES user_id=163326 If there's an alternative way to make the RPM build work, I'll be happy to remove this ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1036908&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2006-05-28 22:30:04
|
Bugs item #1224272, was opened at 2005-06-20 18:23 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1224272&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ben Burton (bab) >Assigned to: Gerhard Häring (ghaering) Summary: Parsing of float values is not locale agnostic Initial Comment: Hi, A report was submitted to the Debian BTS describing a serious bug in pypgsql that can lead to incorrect numerical results in financial applications and the like. The basic problem is that pypgsql uses strtod() for parsing floats, which interprets strings according to the current locale. As a result, if you parse a decimal value (e.g., "1.5") in a locale that uses a comma as a decimal separator (such as de_DE), you get an incorrect value (in this case, 1). Martin Pitt has patched this problem (and I have also applied this patch to the debian packages). I have included the patch as an attachment to this bug. The patch is simple; replace strtod() with PyOS_ascii_strtod(). Since PyOS_ascii_strtod() is only available in python 2.4 and newer, the patch also includes an implementation of this function for use with earlier python versions. For more information on this report, please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311328 . Ben. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2006-05-29 00:29 Message: Logged In: YES user_id=163326 Applied in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1224272&group_id=16528 |
1 message has been excluded from this view by a project administrator.
