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...> - 2005-02-20 05:07:06
|
Patches item #852606, was opened at 2003-12-02 08:40 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528 Category: None Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Patrick Wagstrom (pridkett) Assigned to: Billy G. Allie (ballie01) Summary: Fix for Fedora linux with patched PostgreSQL pacakages Initial Comment: Fedora Linux Core 1 has a patched version of PostgreSQL that reports it's version as 7.3.4-RH which causes the version checking procedure to die and report that we're not connecting to a valid database. This fixes that and makes it so versions that end in "-RH" are recognized as valid versions, allowing pyPgSQL to work under Fedora Core 1 (and I'd imagine anyplace else with the RedHat database). ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-02-20 00:07 Message: Logged In: YES user_id=8500 Applied patch suggested by shauncutts. ---------------------------------------------------------------------- Comment By: Shaun Cutts (shauncutts) Date: 2004-03-11 02:59 Message: Logged In: YES user_id=232124 The following is an alternative solution. Either is needed for RedHat ES as well as Fedora. The submitted version seems to trim out "-RH" wherever it occurs. This variation is to allow -<anything> after the patch # in the version string. A "real" fix for this would be to have newer postgres support version_major() etc functions rather than having to parse strings whose definitions aren't guarenteed. diff pgversion.c-v1.21 pgversion.c 293c293 < token = pg_strtok_r((char *)NULL, ".", &save_ptr); --- > token = pg_strtok_r((char *)NULL, ".-", &save_ptr); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=852606&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-02-20 05:03:32
|
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: Open >Resolution: Postponed 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-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-02-20 04:53:13
|
Patches item #996442, was opened at 2004-07-23 06:18 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=996442&group_id=16528 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Nobody/Anonymous (nobody) Summary: PgSQL.Cursor.__fetchManyRows shoud use xrange Initial Comment: In PgSQL.Cursor.__fetchManyRows range(count) may generate a huge list, if a large count is used. (This happens in combination with ZpyPgSQLDA.db.DB.query with no max_rows set (Its default is 9999999!)) Maybe using xrange can help, it speeds things daratically up. (see also http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-73 ) So I attached a patch to use xrange instead of range. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-02-19 23:53 Message: Logged In: YES user_id=8500 Applied patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=996442&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-02-20 04:50:09
|
Patches item #1002802, was opened at 2004-08-03 14:31 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1002802&group_id=16528 Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: libpqmodule spelling fix Initial Comment: The attached patch contains some trivial spelling fixes ( s/requireed/ required/g ) which we have in pkgsrc for a long time now. They are originally from FreeBSD ports, IIRC. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-02-19 23:50 Message: Logged In: YES user_id=8500 Applied patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1002802&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-02-20 04:48:19
|
Patches item #1029580, was opened at 2004-09-16 20:09 Message generated for change (Comment added) made by ballie01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&group_id=16528 Category: None Group: None >Status: Pending Resolution: None Priority: 8 Submitted By: Jey Kottalam (jeyk) Assigned to: Nobody/Anonymous (nobody) Summary: serious bug: unQuoteBytea allocates buffer that is too small Initial Comment: In the case where unQuoteBytea is called with a string that has no escaped characters, and unQuoteBytea behaves like strcpy() to simply copy all the bytes in the original string unmodified to the destination string, the buffer is too small by one char. The buffer allocated has the size strlen(sin) when it should have the size strlen(sin)+1 to account for the terminating NUL byte in C strings. I have attached a patch to correct this problem. It caused me a lot of pain with strange, semi-random seeming bugs in my program. :-) ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2005-02-19 23:48 Message: Logged In: YES user_id=8500 Applied fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2005-01-16 08:57:20
|
Bugs item #1103260, was opened at 2005-01-16 19:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1103260&group_id=16528 Category: PgInt2 Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1103260&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-11-18 19:11:25
|
Bugs item #1068856, was opened at 2004-11-18 12:20 Message generated for change (Comment added) made by kenlalonde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1068856&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: PgNumeric(0,10,2)._quote() == 'NULL' Initial Comment: A PgNumeric instance with value zero is incorrectly quoted as 'NULL' instead of '0'. Needless to say, this can have nasty consequences. Fix is trivial: in version 2.4 of PgSQL.py: --- PgSQL.py.old 2004-11-18 12:18:49.334613060 -0500 +++ PgSQL.py 2004-11-18 12:18:59.411482575 -0500 @@ -1664,7 +1664,7 @@ return PgNumeric(-self.__v, self.__p, self.__s) def _quote(self, forArray=0): - if self.__v: + if self.__v is not None: if forArray: return '"%s"' % self.__fmtNumeric() else: ---------------------------------------------------------------------- >Comment By: Ken Lalonde (kenlalonde) Date: 2004-11-18 14:11 Message: Logged In: YES user_id=203927 Postscript: same bug affects PgMoney._quote; same fix. While we're here, I see that PgNumeric._quote puts single quotes around the return value. This causes postgres to convert a string to a NUMERIC(S,P) value. Why not omit the quotes and keep it simple? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1068856&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-11-18 17:20:46
|
Bugs item #1068856, was opened at 2004-11-18 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1068856&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: PgNumeric(0,10,2)._quote() == 'NULL' Initial Comment: A PgNumeric instance with value zero is incorrectly quoted as 'NULL' instead of '0'. Needless to say, this can have nasty consequences. Fix is trivial: in version 2.4 of PgSQL.py: --- PgSQL.py.old 2004-11-18 12:18:49.334613060 -0500 +++ PgSQL.py 2004-11-18 12:18:59.411482575 -0500 @@ -1664,7 +1664,7 @@ return PgNumeric(-self.__v, self.__p, self.__s) def _quote(self, forArray=0): - if self.__v: + if self.__v is not None: if forArray: return '"%s"' % self.__fmtNumeric() else: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1068856&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-11-17 07:28:16
|
Bugs item #1067857, was opened at 2004-11-17 08: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=1067857&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Parameter mimatch in PgNumeric.__rmul__ Initial Comment: Line 1598f has to read: def __rmul__(self, other): return self.__mul__(self, other) instead of: def __rmul__(self, other): return self.__mul__(other) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1067857&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-28 13:06:06
|
Bugs item #1056030, was opened at 2004-10-28 13:29 Message generated for change (Comment added) made by peergriebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1056030&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Numeric datatype loses digits Initial Comment: select * from table results in data rows. If the table includes numeric columns digits are truncated: 4.56 will be returned as 4.6. This does not happen using a statement like this: select * from table order by somecolumn ---------------------------------------------------------------------- >Comment By: Peer (peergriebel) Date: 2004-10-28 15:06 Message: Logged In: YES user_id=1133977 After some investigation I discovered some more facts. You need: 0. (Use PgSQL 1.35) 1. A table with at least one numeric column (no precision, no scale) 2. Insert data with different precision. E.g 3.1 and 4.56. 3. SELECT all rows from db with different ordering so that first value (3.1) will be returned first/with second value (4.56) returned first. Then PgSQL tries to determine the precision of the numeric column. Since the databse does not tell it tries to guess (line #2859). It will guess by first value. So if 3.1 comes first it guesses precision is 1. BUT THIS IS WRONG. If the first fetched value is 4.56 it will guess precision is 2. Since the TypeCache uses it's knowlegde for all rows the guessing is sometimes wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1056030&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-28 11:29:59
|
Bugs item #1056030, was opened at 2004-10-28 13:29 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=1056030&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Numeric datatype loses digits Initial Comment: select * from table results in data rows. If the table includes numeric columns digits are truncated: 4.56 will be returned as 4.6. This does not happen using a statement like this: select * from table order by somecolumn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1056030&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-28 11:27:17
|
Bugs item #1041283, was opened at 2004-10-06 11:23 Message generated for change (Comment added) made by peergriebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1041283&group_id=16528 Category: PgSQL Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Transaction must not be aborted in case of OperationalError Initial Comment: I'm using SET statement_timeout to xxx for my database connection. If this timeout is reached the processing of the statement is canceled with an OperationalError. This error is caught by Cursor.execute() which in turn performs a ROLLBACK WORK. If I understand correctly the a statement timeout is _not_ a fatal error. So the transaction must not be rolled back. I would like to see this behaviour explained/fixed. Thank you! ---------------------------------------------------------------------- >Comment By: Peer (peergriebel) Date: 2004-10-28 13:27 Message: Logged In: YES user_id=1133977 I just leart that OperationalErrors are fatal. So it is absolutely valid to abort the transaction :-(( ---------------------------------------------------------------------- Comment By: Peer (peergriebel) Date: 2004-10-06 13:41 Message: Logged In: YES user_id=1133977 The same applies to an OperationalError as a result of an error stating "Cannot insert a duplicate key into unique index ...". This also seems not to be fatal. Nonetheless the transaction is aborted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1041283&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-27 10:02:02
|
Bugs item #1055180, was opened at 2004-10-27 23:02 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=1055180&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike McGavin (jesterzog) Assigned to: Nobody/Anonymous (nobody) Summary: __unicodeConvert doesn't recognise subclasses of UnicodeType Initial Comment: Cursor.__unicodeConvert() (in PgSQL.py) doesn't encode unicode strings all the time. If the object that is passed is of a type that is a subclass of a UnicodeType, rather than of the UnicodeType itself, the __unicodeConvert() method doesn't recognise it as unicode, even though it is. This appears to be because most of the comparisons within the __unicodeConvert() method use the "is" operator to check the object type, which only compares exact types and doesn't take sub-classing into account. This bug may be able to be fixed quite easily, by changing the comparisons (about 7 of them) to use 'isinstance()' instead of the 'is' operator. ie. Instead of: if type(obj) is UnicodeType: doSomething() the code should read: if isinstance(obj, UnicodeType): doSomething() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1055180&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-21 14:23:50
|
Bugs item #1051520, was opened at 2004-10-21 14: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=1051520&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Florquin Renaud (florquin) Assigned to: Nobody/Anonymous (nobody) Summary: __unicodeConvert doesn't support PgArray of Unicode Strings Initial Comment: If we have PgArray of Unicode Strings, PyPgSQL fails. E.g. c = db.cursor() query = "CREATE TABLE test (id TEXT, values TEXT[]); c.execute(query) query = "INSERT INTO test values (%s, %s);" values = [] values.append(1) values.append([u"abc", u"dé"]) c.execute(query, values) c.close() db.commit() File "D:\Soft\Python23\lib\site- packages\pyPgSQL\PgSQL.py", line 3054, in execute parms = _quoteall(parms[0]) File "D:\Soft\Python23\lib\site- packages\pyPgSQL\PgSQL.py", line 2286, in _quoteall t = tuple(map(_quote, vdict)) File "D:\Soft\Python23\lib\site- packages\pyPgSQL\PgSQL.py", line 2255, in _quote return value._quote() File "D:\Soft\Python23\lib\site- packages\pyPgSQL\PgSQL.py", line 1175, in _quote return _handleArray(self.value) File "D:\Soft\Python23\lib\site- packages\pyPgSQL\PgSQL.py", line 2238, in _handleArray _j = '%s%s,' % (_j, PgQuoteString(str(_i), 1)) UnicodeEncodeError: 'ascii' codec can't encode character u'\x82' in position 0: ordinal not in range(128) The cause is that the routine __unicodeConvert doesn't take into account PgArray of Unicode Strings If we modify the __unicodeConvert and add the two marked line then there is no more error: 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 isinstance(item, PgArray): # !!! converted_obj.append(PgArray(self.__unicodeConvert (item.value))) # !!! else: converted_obj.append(item) return converted_obj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1051520&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-06 11:41:46
|
Bugs item #1041283, was opened at 2004-10-06 11:23 Message generated for change (Comment added) made by peergriebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1041283&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Transaction must not be aborted in case of OperationalError Initial Comment: I'm using SET statement_timeout to xxx for my database connection. If this timeout is reached the processing of the statement is canceled with an OperationalError. This error is caught by Cursor.execute() which in turn performs a ROLLBACK WORK. If I understand correctly the a statement timeout is _not_ a fatal error. So the transaction must not be rolled back. I would like to see this behaviour explained/fixed. Thank you! ---------------------------------------------------------------------- >Comment By: Peer (peergriebel) Date: 2004-10-06 13:41 Message: Logged In: YES user_id=1133977 The same applies to an OperationalError as a result of an error stating "Cannot insert a duplicate key into unique index ...". This also seems not to be fatal. Nonetheless the transaction is aborted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1041283&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-06 09:23:04
|
Bugs item #1041283, was opened at 2004-10-06 11: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=1041283&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer (peergriebel) Assigned to: Nobody/Anonymous (nobody) Summary: Transaction must not be aborted in case of OperationalError Initial Comment: I'm using SET statement_timeout to xxx for my database connection. If this timeout is reached the processing of the statement is canceled with an OperationalError. This error is caught by Cursor.execute() which in turn performs a ROLLBACK WORK. If I understand correctly the a statement timeout is _not_ a fatal error. So the transaction must not be rolled back. I would like to see this behaviour explained/fixed. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1041283&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-05 08:11:25
|
Bugs item #1006782, was opened at 2004-08-10 20:49 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2004-10-05 10:11 Message: Logged In: YES user_id=163326 Looks like it's time to get a few bugs fixed and make a release that will work with Pg8. ---------------------------------------------------------------------- Comment By: John F Meinel Jr (jfmeinel) Date: 2004-09-08 18:26 Message: Logged In: YES user_id=266114 I am unable to build from source. I have Visual Studio 7.1, and not 6 to compile the library. Can you run "py setup.py bdist_wininst" for me and either post the installer, or send it to me? Thanks, John =:-> ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 13:19 Message: Logged In: YES user_id=665785 Thank you very much, mfuhr... I looked at the "devel" check and propose to do if (pgstricmp(last, "beta", 4) == 0) return (errno != 0); instead of strncmp ... I suppose the PostgreSQL developers had their reason to provide their own strcmp, or? ---------------------------------------------------------------------- Comment By: Michael Fuhr (mfuhr) Date: 2004-08-24 05:47 Message: Logged In: YES user_id=655499 PgVersion_New() calls parseToken(), which doesn't allow for the string "beta" in the last token of "8.0.0beta1". parseToken() checks for "devel" and a few other cases, but not for "beta". I got it to work by adding the following lines after the check for "devel": if (strncmp(last, "beta", 4) == 0) return (errno != 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-10-05 08:09:50
|
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 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: rangzen (rangzen) Assigned to: Nobody/Anonymous (nobody) 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...> - 2004-10-05 08:08:43
|
Bugs item #855986, was opened at 2003-12-08 01:26 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=855986&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Burton (bab) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot connect to postgresql-7.4betaX databases Initial Comment: (Received through the Debian BTS as #219862.) The PostgreSQL version string that is reported by postgresql-7.4beta5 (and all other betas) cannot be parsed by the pypgsql code. The problem is that the 'beta' in the version number confuses the parser in pgversion.c (in particular lines 277 and on, in the function PgVersion_New) which creates a PgVersion object from the string that the server reports. The function errors out and the connection fails. Thanks! ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2004-10-05 10:08 Message: Logged In: YES user_id=163326 Can we drop the pgversion stuff? Alternatively, we must make it more robust. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=855986&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-09-29 10:08:17
|
Bugs item #1036908, was opened at 2004-09-29 12:08 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=1036908&group_id=16528 Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: rangzen (rangzen) Assigned to: Nobody/Anonymous (nobody) 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 ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1036908&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-09-17 00:09:43
|
Patches item #1029580, was opened at 2004-09-16 17:09 Message generated for change (Settings changed) made by jeyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&group_id=16528 Category: None Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Jey Kottalam (jeyk) Assigned to: Nobody/Anonymous (nobody) Summary: serious bug: unQuoteBytea allocates buffer that is too small Initial Comment: In the case where unQuoteBytea is called with a string that has no escaped characters, and unQuoteBytea behaves like strcpy() to simply copy all the bytes in the original string unmodified to the destination string, the buffer is too small by one char. The buffer allocated has the size strlen(sin) when it should have the size strlen(sin)+1 to account for the terminating NUL byte in C strings. I have attached a patch to correct this problem. It caused me a lot of pain with strange, semi-random seeming bugs in my program. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-09-17 00:09:22
|
Patches item #1029580, was opened at 2004-09-16 17:09 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=1029580&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jey Kottalam (jeyk) Assigned to: Nobody/Anonymous (nobody) Summary: serious bug: unQuoteBytea allocates buffer that is too small Initial Comment: In the case where unQuoteBytea is called with a string that has no escaped characters, and unQuoteBytea behaves like strcpy() to simply copy all the bytes in the original string unmodified to the destination string, the buffer is too small by one char. The buffer allocated has the size strlen(sin) when it should have the size strlen(sin)+1 to account for the terminating NUL byte in C strings. I have attached a patch to correct this problem. It caused me a lot of pain with strange, semi-random seeming bugs in my program. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1029580&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-09-08 16:26:28
|
Bugs item #1006782, was opened at 2004-08-10 13:49 Message generated for change (Comment added) made by jfmeinel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: pyPGSQL does not connect to PostgreSQL 8.0 Beta Initial Comment: While trying to connect to Postgresql 8.0, PyPGSQL raises Invalid format for PgVersion construction. Error. That's seems to be within PyObject *PgVersion_New(char *version) of pgversion.c What is going wrong? ---------------------------------------------------------------------- Comment By: John F Meinel Jr (jfmeinel) Date: 2004-09-08 11:26 Message: Logged In: YES user_id=266114 I am unable to build from source. I have Visual Studio 7.1, and not 6 to compile the library. Can you run "py setup.py bdist_wininst" for me and either post the installer, or send it to me? Thanks, John =:-> ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 06:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 06:20 Message: Logged In: YES user_id=665785 correcting myself... if (pgstricmp(last, "beta") == 0) return (errno != 0); pgstricmp does not take any length parameter ---------------------------------------------------------------------- Comment By: Harald Armin Massa (ghum) Date: 2004-08-25 06:19 Message: Logged In: YES user_id=665785 Thank you very much, mfuhr... I looked at the "devel" check and propose to do if (pgstricmp(last, "beta", 4) == 0) return (errno != 0); instead of strncmp ... I suppose the PostgreSQL developers had their reason to provide their own strcmp, or? ---------------------------------------------------------------------- Comment By: Michael Fuhr (mfuhr) Date: 2004-08-23 22:47 Message: Logged In: YES user_id=655499 PgVersion_New() calls parseToken(), which doesn't allow for the string "beta" in the last token of "8.0.0beta1". parseToken() checks for "devel" and a few other cases, but not for "beta". I got it to work by adding the following lines after the check for "devel": if (strncmp(last, "beta", 4) == 0) return (errno != 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1006782&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-09-08 16:24:34
|
Bugs item #1024508, was opened at 2004-09-08 11:19 Message generated for change (Comment added) made by jfmeinel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1024508&group_id=16528 Category: libpq Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: John F Meinel Jr (jfmeinel) Assigned to: Nobody/Anonymous (nobody) Summary: Postgres 8.0beta invalid format for PgVersion Initial Comment: I'm trying to test the latest Postgres beta on windows (8.0beta), and I am unable to connect because I get the error: "libpq.DatabaseError: Ivalid format for PgVersion construction." The string is: select version(); "PostgreSQL 8.0.0beta2 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.2.3 (mingw special 20030504-1)" I'm guessing libpq is unhappy about the "0beta2" part. In pgversion.c, function parseToken I see that it is okay with the form PostgreSQL 8.0.0b1 But not the string "beta1". Is it possible to get it adjusted to compare for "beta" and possibly "alpha" as well? Perhaps it is non-standard for the PostgreSQL people to use "beta" instead of just "b", so I should tell them to change.:) If PgSQL is changed, can someone compile the Win32 installer for me? I only have MSVisual Studio 7.1, and python says you need 6 to compile extensions. I tried forcing it, but it still didn't work. Thanks for the help, John =:-> ---------------------------------------------------------------------- >Comment By: John F Meinel Jr (jfmeinel) Date: 2004-09-08 11:24 Message: Logged In: YES user_id=266114 Sorry, this is a dupe of this: 1006782 I'll post my comments there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1024508&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2004-09-08 16:19:19
|
Bugs item #1024508, was opened at 2004-09-08 11:19 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=1024508&group_id=16528 Category: libpq Group: None Status: Open Resolution: None Priority: 5 Submitted By: John F Meinel Jr (jfmeinel) Assigned to: Nobody/Anonymous (nobody) Summary: Postgres 8.0beta invalid format for PgVersion Initial Comment: I'm trying to test the latest Postgres beta on windows (8.0beta), and I am unable to connect because I get the error: "libpq.DatabaseError: Ivalid format for PgVersion construction." The string is: select version(); "PostgreSQL 8.0.0beta2 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.2.3 (mingw special 20030504-1)" I'm guessing libpq is unhappy about the "0beta2" part. In pgversion.c, function parseToken I see that it is okay with the form PostgreSQL 8.0.0b1 But not the string "beta1". Is it possible to get it adjusted to compare for "beta" and possibly "alpha" as well? Perhaps it is non-standard for the PostgreSQL people to use "beta" instead of just "b", so I should tell them to change.:) If PgSQL is changed, can someone compile the Win32 installer for me? I only have MSVisual Studio 7.1, and python says you need 6 to compile extensions. I tried forcing it, but it still didn't work. Thanks for the help, John =:-> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1024508&group_id=16528 |
1 message has been excluded from this view by a project administrator.
