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-01-19 11:03:44
|
Bugs item #1409818, was opened at 2006-01-19 12:03 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1409818&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-10-16 09:48:21
|
Bugs item #1327846, was opened at 2005-10-16 02:48 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=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: Open Resolution: None 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". :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1327846&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-10-14 09:51:18
|
Bugs item #1325835, was opened at 2005-10-13 15:57 Message generated for change (Comment added) made by ghum 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: Open Resolution: None 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: 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...> - 2005-10-14 05:04:45
|
Bugs item #1325835, was opened at 2005-10-13 09:57 Message generated for change (Comment added) made by ballie01 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: Open Resolution: None >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: Billy G. Allie (ballie01) Date: 2005-10-14 01: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 10: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...> - 2005-10-13 14:07:52
|
Bugs item #1325835, was opened at 2005-10-13 15:57 Message generated for change (Comment added) made by ghum 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: libpq Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) 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: 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...> - 2005-10-13 13:57:47
|
Bugs item #1325835, was opened at 2005-10-13 15: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=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: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1325835&group_id=16528 |
|
From: <gh...@fm...> - 2005-08-19 13:20:08
|
Hi all! I want to know if there is possible to send a dictionary to a pypgsql function (as function parameter, off course), which will save me = a lot of work. If there isn't: Some could guide me or give me some tips to where can i found the "arguments check" routine to try to do it? Thanks. --=20 Gerardo Herzig Direccion General de Organizacion y Sistemas Facultad de Medicina U.B.A. |
|
From: Michael H. <Mi...@Hi...> - 2005-08-15 15:09:39
|
Hello,
Playing around with the "notify" capability, but I find that demo2a.py
regularly crashes. It will do this fairly consistently after 3 - 4
notifications have been received. I'm using the demo2a file unmodified
except for using my own database/table info. I'm using psql to do
"NOTIFY mytable;".
It seems to crash on the line indicated below.
while 1:
# Wait a little (using select())
sys.stdout.flush()
ready_sockets = select.select([cnx.socket], [], [], 1.0)[0]
if len(ready_sockets) == 0:
sys.stdout.write('.')
else:
sys.stdout.write('\n')
cnx.consumeInput()
note = cnx.notifies() <--- Crashes here
while note:
I'm on Win2k using PostgreSQL 8.0.3, Python 2.4.1 and the version of
pyPgSQL released by Gerhard that works with the above.
The symptom is the program freezes and Windows reports that "python.exe
has generated errors and will be closed". Windows reports it is creating
a log, but I can't seem to find it.
Any ideas?
Thanks,
Michael Hipp
|
|
From: SourceForge.net <no...@so...> - 2005-06-20 16:28:58
|
Bugs item #1224276, was opened at 2005-06-21 02:28 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=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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1224276&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-06-20 16:23:35
|
Bugs item #1224272, was opened at 2005-06-21 02:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=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: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1224272&group_id=16528 |
|
From: Andrew M. <an...@ob...> - 2005-05-24 02:22:46
|
Looking through the bug reports, I see the following report:
There is a problem with parsing German datestyle by
the DateTime.ISO.ParseAny:
ValueError: unsupported format: "19.09.2003";
Maybe DateTime.Parser.DateTimeFromString is better?
I think making the parsing more generous is a mistake - pypgsql should
explicitly tell the postgres libs what date format it generates and
expects (via SET datestyle TO 'ISO,European'), rather than try to guess.
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
|
|
From: SourceForge.net <no...@so...> - 2005-05-16 03:40:30
|
Bugs item #1178976, was opened at 2005-04-07 23:10 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 Category: PgResult Group: None >Status: Pending >Resolution: Fixed Priority: 7 Submitted By: Ben Rampling (benr_web) Assigned to: Billy G. Allie (ballie01) Summary: unQuoteBytea adds an extraneous NUL byte Initial Comment: "unQuoteBytea" in libpqmodule.c was modified between release 2.4 and the current CVS version. The function starts: PyObject *unQuoteBytea(char *sin) { int i, j, slen, byte; char *sout; PyObject *result; slen = strlen(sin) + 1; /* ! */ In release 2.4 the last line was: slen = strlen(sin); As a result of this change, if you do: cursor.execute("SELECT 'Quick Brown'::bytea") and then print the result, you get: 'Quick Brown\x00' In the release version 2.4, you get what I would expect: 'Quick Brown' Looking at all of unQuoteBytea, it looks quite safe to just remove the + 1. The entire function treats sout as a memory buffer possibly containing null characters, with the length in slen. Py_BuildValue is using "s#" as the format and doesn't require or want any terminator. Perhaps this happened when the fixes for libPQquoteBytea were being applied? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2005-04-08 20:45 Message: Logged In: YES user_id=8500 After my previous post, I went back and did some checking. You are correct. The length should only be strlen(sin), not strlen(sin) + 1. I will fix the code. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2005-04-08 15:15 Message: Logged In: YES user_id=8500 The change was made becuase the behaviour you expect is not correct. 'The quick brown fox'::bytea is 'The quick brown fox0x00' (remeber that 0x00 is a valid character in bytea strings). The previous behaviour could cause a buffer overflow condition in certain instances. See http://sourceforge.net/tracker/index.php?func=detail&aid=1029580&group_id=16528&atid=316528 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-05-16 03:39:07
|
Bugs item #1199311, was opened at 2005-05-10 14:54 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1199311&group_id=16528 Category: PgSQL Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Damon Hart (damonhart) >Assigned to: Billy G. Allie (ballie01) Summary: timestamp/timezone handling error in CVS head (OK in 2.4.0) Initial Comment: Please find attached a transcript of a psql session creating a trivial test table and inserting/retrieving one timestamp. Also attached are transcripts of two interactive Python sessions using PgSQL, one from CVS head (as of 2005-05-04) the other the 2.4.0 release (installed via RPM.) The timestamp retrieved with 2.4.0 looks OK, but the one retrieved using CVS head is four hours ahead. I'll speculate that this is a timezone issue, since the machine's timezone (both client and server) is America/New_York and is currently 4 hours behind UTC. Environment: all software on one machine, Fedora Core 3 with PostgreSQL updated to 8.0.2 via PGDG RPMs. egenix-mx-base-2.0.6-py2.3_ucs4_1 from RPM for the datetime handling. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2005-05-15 22:59 Message: Logged In: YES user_id=8500 The method used to parse dates was change in the current CVS head from ISO.ParseAny() to Parser.DateTimeFromString(). This change was made to better handle dates in various locals. The ISO.ParseAny() method returns a local datetime instance. The Parser.DateTimeFromString() method returns a UTC datetime instance. Since the previous behaviour was to return a local time instance, I will modify the code to get a local time instance from the datetime instance returned by Parser.DateTimeFromString(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1199311&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-05-16 02:59:43
|
Bugs item #1199311, was opened at 2005-05-10 14:54 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1199311&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Damon Hart (damonhart) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp/timezone handling error in CVS head (OK in 2.4.0) Initial Comment: Please find attached a transcript of a psql session creating a trivial test table and inserting/retrieving one timestamp. Also attached are transcripts of two interactive Python sessions using PgSQL, one from CVS head (as of 2005-05-04) the other the 2.4.0 release (installed via RPM.) The timestamp retrieved with 2.4.0 looks OK, but the one retrieved using CVS head is four hours ahead. I'll speculate that this is a timezone issue, since the machine's timezone (both client and server) is America/New_York and is currently 4 hours behind UTC. Environment: all software on one machine, Fedora Core 3 with PostgreSQL updated to 8.0.2 via PGDG RPMs. egenix-mx-base-2.0.6-py2.3_ucs4_1 from RPM for the datetime handling. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-05-15 22:59 Message: Logged In: YES user_id=8500 The method used to parse dates was change in the current CVS head from ISO.ParseAny() to Parser.DateTimeFromString(). This change was made to better handle dates in various locals. The ISO.ParseAny() method returns a local datetime instance. The Parser.DateTimeFromString() method returns a UTC datetime instance. Since the previous behaviour was to return a local time instance, I will modify the code to get a local time instance from the datetime instance returned by Parser.DateTimeFromString(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1199311&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 18:54:48
|
Bugs item #1199311, was opened at 2005-05-10 14:54 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=1199311&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Damon Hart (damonhart) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp/timezone handling error in CVS head (OK in 2.4.0) Initial Comment: Please find attached a transcript of a psql session creating a trivial test table and inserting/retrieving one timestamp. Also attached are transcripts of two interactive Python sessions using PgSQL, one from CVS head (as of 2005-05-04) the other the 2.4.0 release (installed via RPM.) The timestamp retrieved with 2.4.0 looks OK, but the one retrieved using CVS head is four hours ahead. I'll speculate that this is a timezone issue, since the machine's timezone (both client and server) is America/New_York and is currently 4 hours behind UTC. Environment: all software on one machine, Fedora Core 3 with PostgreSQL updated to 8.0.2 via PGDG RPMs. egenix-mx-base-2.0.6-py2.3_ucs4_1 from RPM for the datetime handling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1199311&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-04-22 02:15:35
|
Bugs item #1187803, was opened at 2005-04-22 11: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=1187803&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None 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) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1187803&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-04-19 15:34:16
|
Bugs item #1186055, was opened at 2005-04-19 17:34 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=1186055&group_id=16528 Category: PgConnection Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1186055&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-04-09 00:45:38
|
Bugs item #1178976, was opened at 2005-04-07 23:10 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Ben Rampling (benr_web) Assigned to: Billy G. Allie (ballie01) Summary: unQuoteBytea adds an extraneous NUL byte Initial Comment: "unQuoteBytea" in libpqmodule.c was modified between release 2.4 and the current CVS version. The function starts: PyObject *unQuoteBytea(char *sin) { int i, j, slen, byte; char *sout; PyObject *result; slen = strlen(sin) + 1; /* ! */ In release 2.4 the last line was: slen = strlen(sin); As a result of this change, if you do: cursor.execute("SELECT 'Quick Brown'::bytea") and then print the result, you get: 'Quick Brown\x00' In the release version 2.4, you get what I would expect: 'Quick Brown' Looking at all of unQuoteBytea, it looks quite safe to just remove the + 1. The entire function treats sout as a memory buffer possibly containing null characters, with the length in slen. Py_BuildValue is using "s#" as the format and doesn't require or want any terminator. Perhaps this happened when the fixes for libPQquoteBytea were being applied? ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-04-08 20:45 Message: Logged In: YES user_id=8500 After my previous post, I went back and did some checking. You are correct. The length should only be strlen(sin), not strlen(sin) + 1. I will fix the code. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2005-04-08 15:15 Message: Logged In: YES user_id=8500 The change was made becuase the behaviour you expect is not correct. 'The quick brown fox'::bytea is 'The quick brown fox0x00' (remeber that 0x00 is a valid character in bytea strings). The previous behaviour could cause a buffer overflow condition in certain instances. See http://sourceforge.net/tracker/index.php?func=detail&aid=1029580&group_id=16528&atid=316528 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-04-08 19:15:59
|
Bugs item #1178976, was opened at 2005-04-07 23:10 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Rampling (benr_web) >Assigned to: Billy G. Allie (ballie01) Summary: unQuoteBytea adds an extraneous NUL byte Initial Comment: "unQuoteBytea" in libpqmodule.c was modified between release 2.4 and the current CVS version. The function starts: PyObject *unQuoteBytea(char *sin) { int i, j, slen, byte; char *sout; PyObject *result; slen = strlen(sin) + 1; /* ! */ In release 2.4 the last line was: slen = strlen(sin); As a result of this change, if you do: cursor.execute("SELECT 'Quick Brown'::bytea") and then print the result, you get: 'Quick Brown\x00' In the release version 2.4, you get what I would expect: 'Quick Brown' Looking at all of unQuoteBytea, it looks quite safe to just remove the + 1. The entire function treats sout as a memory buffer possibly containing null characters, with the length in slen. Py_BuildValue is using "s#" as the format and doesn't require or want any terminator. Perhaps this happened when the fixes for libPQquoteBytea were being applied? ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-04-08 15:15 Message: Logged In: YES user_id=8500 The change was made becuase the behaviour you expect is not correct. 'The quick brown fox'::bytea is 'The quick brown fox0x00' (remeber that 0x00 is a valid character in bytea strings). The previous behaviour could cause a buffer overflow condition in certain instances. See http://sourceforge.net/tracker/index.php?func=detail&aid=1029580&group_id=16528&atid=316528 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-04-08 03:10:19
|
Bugs item #1178976, was opened at 2005-04-08 03:10 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=1178976&group_id=16528 Category: PgResult Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Rampling (benr_web) Assigned to: Nobody/Anonymous (nobody) Summary: unQuoteBytea adds an extraneous NUL byte Initial Comment: "unQuoteBytea" in libpqmodule.c was modified between release 2.4 and the current CVS version. The function starts: PyObject *unQuoteBytea(char *sin) { int i, j, slen, byte; char *sout; PyObject *result; slen = strlen(sin) + 1; /* ! */ In release 2.4 the last line was: slen = strlen(sin); As a result of this change, if you do: cursor.execute("SELECT 'Quick Brown'::bytea") and then print the result, you get: 'Quick Brown\x00' In the release version 2.4, you get what I would expect: 'Quick Brown' Looking at all of unQuoteBytea, it looks quite safe to just remove the + 1. The entire function treats sout as a memory buffer possibly containing null characters, with the length in slen. Py_BuildValue is using "s#" as the format and doesn't require or want any terminator. Perhaps this happened when the fixes for libPQquoteBytea were being applied? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1178976&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-03-06 05:11:05
|
Patches item #987719, was opened at 2004-07-08 23:55 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=987719&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Accepted Priority: 5 Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: Access to SQLSTATE + memory leak Initial Comment: It would be nice if one had access to the postgresql 5 character "SQLSTATE" error code, to, for example, unambiguously determine if a serialization error happened and the transaction should be re-run. The error code is more precise and future-proof than a substring check on the textual error message. I've attached a patch to the 2.4 version of pgconnection.c. It changes the value of a libpq.OperationalError exception to a tuple: (sqlstate, message), a la OSError. This fix is sufficient, but I lack the pythonic karma to say if it's the best way. I added a missing PQclear() call too. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-03-06 00:11 Message: Logged In: YES user_id=8500 Added the missing PQclear() call. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2005-02-20 00:03 Message: Logged In: YES user_id=8500 This requires libpq protocol 3 in order to work. I will investigate what is needed to maintain compatibility with protovol version 2 of libpq. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=987719&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-03-06 04:57:34
|
Patches item #1154791, was opened at 2005-03-01 22:53 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1154791&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Andrew McNamara (andrewmcnamara) Assigned to: Nobody/Anonymous (nobody) Summary: Postgres include files in /usr/include/postgresql on Debian Initial Comment: Postgresql include files are in /usr/include/postgresql on Debian systems. This patch adds this directory to the setup.py include_dirs. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-03-05 23:57 Message: Logged In: YES user_id=8500 Added to CVS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1154791&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-03-06 04:57:09
|
Patches item #1154792, was opened at 2005-03-01 22:55 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1154792&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Andrew McNamara (andrewmcnamara) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error, and logic error fix for PgSQL.py Initial Comment: Syntax error and execute() method calls self.conn.conn.query twice when parms is a tuple or list. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-03-05 23:57 Message: Logged In: YES user_id=8500 Added to CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1154792&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-03-06 04:51:05
|
Bugs item #809127, was opened at 2003-09-19 03:30 Message generated for change (Settings changed) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=809127&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 6 Submitted By: Sergey Suleymanov (solt) Assigned to: Billy G. Allie (ballie01) Summary: DateTime parsing Initial Comment: There is a problem with parsing German datestyle by the DateTime.ISO.ParseAny: ValueError: unsupported format: "19.09.2003" Maybe DateTime.Parser.DateTimeFromString is better? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=809127&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-03-02 03:55:32
|
Patches item #1154792, was opened at 2005-03-02 14:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1154792&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew McNamara (andrewmcnamara) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error, and logic error fix for PgSQL.py Initial Comment: Syntax error and execute() method calls self.conn.conn.query twice when parms is a tuple or list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1154792&group_id=16528 |
1 message has been excluded from this view by a project administrator.
