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...> - 2003-03-04 12:41:28
|
Bugs item #697221, was opened at 2003-03-04 13:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=697221&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Michael Howitz (icemac) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError: value too large for PgNumeric Initial Comment: I create a table: CREATE TABLE test_bug ( t NUMERIC(10,2) ); Then I insert two values: INSERT INTO test_bug VALUES (24.11); INSERT INTO test_bug VALUES (305.03); Now I query the values through ZOPE using: SELECT t FROM test_bug UNION SELECT 0 ORDER BY t ASC The result is: OverflowError: value too large for PgNumeric Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.ZRDB.DA, line 331, in manage_test * Module Shared.DC.ZRDB.DA, line 309, in manage_test * Module Shared.DC.ZRDB.DA, line 443, in __call__ * Module Products.ZpyPgSQLDA.db, line 148, in query * Module pyPgSQL.PgSQL, line 3074, in fetchmany * Module pyPgSQL.PgSQL, line 2688, in __fetchManyRows * Module pyPgSQL.PgSQL, line 2664, in __fetchOneRow * Module pyPgSQL.PgSQL, line 719, in typecast * Module pyPgSQL.PgSQL, line 1336, in __init__ The Exception does not happen, when I leave out the UNION-statment (but I need it) or if I order by desc (but this is no solution). It seems that the precision for the column is computed as the precision of the first value. my Versions: Zope Version: (unreleased version, python 2.2.2, linux2) Python Version: 2.2.2 (#3, Dec 15 2002, 15:08:50) [GCC 2.95.4 20011002 (Debian prerelease)] I use ZpyPgSQLDA. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=697221&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-03-04 12:38:56
|
Bugs item #697221, was opened at 2003-03-04 13:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=697221&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Howitz (icemac) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError: value too large for PgNumeric Initial Comment: I create a table: CREATE TABLE test_bug ( t NUMERIC(10,2) ); Then I insert two values: INSERT INTO test_bug VALUES (24.11); INSERT INTO test_bug VALUES (305.03); Now I query the values through ZOPE using: SELECT t FROM test_bug UNION SELECT 0 ORDER BY t ASC The result is: OverflowError: value too large for PgNumeric Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.ZRDB.DA, line 331, in manage_test * Module Shared.DC.ZRDB.DA, line 309, in manage_test * Module Shared.DC.ZRDB.DA, line 443, in __call__ * Module Products.ZpyPgSQLDA.db, line 148, in query * Module pyPgSQL.PgSQL, line 3074, in fetchmany * Module pyPgSQL.PgSQL, line 2688, in __fetchManyRows * Module pyPgSQL.PgSQL, line 2664, in __fetchOneRow * Module pyPgSQL.PgSQL, line 719, in typecast * Module pyPgSQL.PgSQL, line 1336, in __init__ The Exception does not happen, when I leave out the UNION-statment (but I need it) or if I order by desc (but this is no solution). It seems that the precision for the column is computed as the precision of the first value. my Versions: Zope Version: (unreleased version, python 2.2.2, linux2) Python Version: 2.2.2 (#3, Dec 15 2002, 15:08:50) [GCC 2.95.4 20011002 (Debian prerelease)] I use ZpyPgSQLDA. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=697221&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-03-02 11:30:31
|
Bugs item #694358, was opened at 2003-02-27 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Billy G. Allie (ballie01) Summary: Buggy __radd__ in PgNumeric Initial Comment: [vivek kumar sent this to DB-SIG] hi all, I am sending this mail at this address coz i was unable to find some address for reporting possible bug in pyPgSQL and the +pyPgSQL project page was not opening (slow net speed). This may be a bug left in the pyPgSQL version 2.3. When i try to add some numeric data returned by query (PgNumeric) then it +gives me name error (global __add__ not found). The actual code for the __radd__ in PgNumeric was def __radd__(self,other): return __add__(self,other) A possible work around (it worked for me) may be def __radd__(self,other): return self.__add__(other) regards vivek kumar ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2003-03-02 12:40 Message: Logged In: YES user_id=163326 Billy, would you like to take a look at this one? I'm quite puzzled with the workings of PgNumeric. Once the obvious bug (self in wrong place) is fixed, there's more that doesn't work: >>> 3 + PgNumeric("-5.0") Traceback (most recent call last): File "<stdin>", line 1, in ? File "pyPgSQL/PgSQL.py", line 1495, in __radd__ return self.__add__(other) File "pyPgSQL/PgSQL.py", line 1492, in __add__ return PgNumeric((_s + _o), (mp + ms), ms) File "pyPgSQL/PgSQL.py", line 1262, in __init__ raise OverflowError, "value too large for PgNumeric" OverflowError: value too large for PgNumeric __rsub__ seems to be problematic, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-02-27 13:25:28
|
Bugs item #694358, was opened at 2003-02-27 14:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528 Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Gerhard Häring (ghaering) Summary: Buggy __radd__ in PgNumeric Initial Comment: [vivek kumar sent this to DB-SIG] hi all, I am sending this mail at this address coz i was unable to find some address for reporting possible bug in pyPgSQL and the +pyPgSQL project page was not opening (slow net speed). This may be a bug left in the pyPgSQL version 2.3. When i try to add some numeric data returned by query (PgNumeric) then it +gives me name error (global __add__ not found). The actual code for the __radd__ in PgNumeric was def __radd__(self,other): return __add__(self,other) A possible work around (it worked for me) may be def __radd__(self,other): return self.__add__(other) regards vivek kumar ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=694358&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-02-17 13:06:03
|
Bugs item #656798, was opened at 2002-12-20 14:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Maas (petermaas) Assigned to: Gerhard Häring (ghaering) Summary: ZpyPgSQLDA failure in ZOPE 2.6 / Win2k Initial Comment: I try to access postgresql 7.1 db on linux server with ZpyPgSQLDA. running on Zope 2.6.0 (python 2.1.3) on Win2000. On database1 (which I don't own) a SELECT on a 665 rows table yields the ZOPE error: Error Type: RuntimeError Error Value: maximum recursion depth exceeded A SELECT on a 22 rows table yields: This statement returned no results. On another database (which I own) on the same server I get the desired result (10 row table) but it takes quite long (about 5 seconds). I tried all cases in Python 2.1.3 (and Python 2.2) directly with pyPgSQL and everything worked well (got the results nearly immediately). So I suspect that there's something wrong with Zope or ZpyPgSQLDA. Regards, Peter. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2003-02-17 14:13 Message: Logged In: YES user_id=163326 Sorry, I haven't looked into ZpyPgSQLDA for ages. Probably because I currently don't use ZOPE myself. Considering this, I'd suggest you check out ZpsycopgDA instead, as it's likely better supported at this time. There seem to be win32 binaries available at http://www.zope.org/Members/pvl/PsycopgWin32/psycopgWin32/view I hate to have to recommend the "competition", but looked at raitionally, this is most likely the best solution for now. Sorry for the inconvenience. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-02-17 05:29:42
|
Bugs item #656798, was opened at 2002-12-20 08:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Maas (petermaas) >Assigned to: Gerhard Häring (ghaering) Summary: ZpyPgSQLDA failure in ZOPE 2.6 / Win2k Initial Comment: I try to access postgresql 7.1 db on linux server with ZpyPgSQLDA. running on Zope 2.6.0 (python 2.1.3) on Win2000. On database1 (which I don't own) a SELECT on a 665 rows table yields the ZOPE error: Error Type: RuntimeError Error Value: maximum recursion depth exceeded A SELECT on a 22 rows table yields: This statement returned no results. On another database (which I own) on the same server I get the desired result (10 row table) but it takes quite long (about 5 seconds). I tried all cases in Python 2.1.3 (and Python 2.2) directly with pyPgSQL and everything worked well (got the results nearly immediately). So I suspect that there's something wrong with Zope or ZpyPgSQLDA. Regards, Peter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-02-17 05:28:41
|
Bugs item #653044, was opened at 2002-12-12 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2003-02-17 00:36 Message: Logged In: YES user_id=8500 It is now fixed in CVS. ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-19 16:12 Message: Logged In: YES user_id=88611 I forgot to atach the patch... ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-19 16:11 Message: Logged In: YES user_id=88611 Apply the attached patch and it will be perfect !! (I have just upgraded to 7.3 and IMO my friend does not have set the date format to ISO. Isn't there some kind of 'SET DATEFORMAT TO ISO' or something like that in Postgres to force this format for a connection?) The patch fixes problems with simple values like '2 hours', '2 days' etc. It seems to me you tested it only on the complex ones. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 00:16 Message: Logged In: YES user_id=8500 I have just commited a patch to PgSQL.py that will fix the problem with theinterval parsing. Ondrej, Can you confirm that it corrects the poblem you were having. Thanks. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 09:27 Message: Logged In: YES user_id=8500 Try this: In psql insert '1 year 3 week 3 day ago'. Retrieve the value from the table using psql. Retrieve the value using pyPgSQL. It's broken. Also, can you or your friend submit a bug report about the problem and the change to ISO needed to make it work? Thanks. BTW: I will be commiting a fix for the interval problem today. ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-13 04:03 Message: Logged In: YES user_id=88611 BTW: There is a problem with DateTime type in Postgres 7.3 too. 7.2.3 works OK, but a friend reported that in 7.3 he had to modify the mx.DateTime.ISO . I think you should test it on this version too. As for the 'interval', 7.2.3 can eat postgres output correctly, I had only a problem with the conversion python->postgres. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 02:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2003-02-17 01:40:32
|
Patches item #653540, was opened at 2002-12-13 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dave Peticolas (jdavisp3) Assigned to: Nobody/Anonymous (nobody) Summary: Fix spelling in error messages. Initial Comment: Fix spelling in error messages. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2003-02-16 20:48 Message: Logged In: YES user_id=8500 The pach has been applied. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-12-16 20:47 Message: Logged In: YES user_id=163326 You need to check the checkbox "Check to Upload and Attach a File: [ ]" in order for the upload to work. It's a Sourceforge annoyance we can do nothing about :-( This happened to me several times before, even though I should know about this by now. ---------------------------------------------------------------------- Comment By: Dave Peticolas (jdavisp3) Date: 2002-12-14 16:36 Message: Logged In: YES user_id=9778 I'm not sure why uploading didn't work the first time, but it seems to have worked now. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 16:26 Message: Logged In: YES user_id=8500 Dave, The patch did not appear. Could you re-upload the patch. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 |
|
From: <no...@so...> - 2002-12-20 13:27:31
|
Bugs item #656798, was opened at 2002-12-20 14:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Maas (petermaas) Assigned to: Nobody/Anonymous (nobody) Summary: ZpyPgSQLDA failure in ZOPE 2.6 / Win2k Initial Comment: I try to access postgresql 7.1 db on linux server with ZpyPgSQLDA. running on Zope 2.6.0 (python 2.1.3) on Win2000. On database1 (which I don't own) a SELECT on a 665 rows table yields the ZOPE error: Error Type: RuntimeError Error Value: maximum recursion depth exceeded A SELECT on a 22 rows table yields: This statement returned no results. On another database (which I own) on the same server I get the desired result (10 row table) but it takes quite long (about 5 seconds). I tried all cases in Python 2.1.3 (and Python 2.2) directly with pyPgSQL and everything worked well (got the results nearly immediately). So I suspect that there's something wrong with Zope or ZpyPgSQLDA. Regards, Peter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=656798&group_id=16528 |
|
From: <no...@so...> - 2002-12-19 21:12:17
|
Bugs item #653044, was opened at 2002-12-13 01:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-19 22:12 Message: Logged In: YES user_id=88611 I forgot to atach the patch... ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-19 22:11 Message: Logged In: YES user_id=88611 Apply the attached patch and it will be perfect !! (I have just upgraded to 7.3 and IMO my friend does not have set the date format to ISO. Isn't there some kind of 'SET DATEFORMAT TO ISO' or something like that in Postgres to force this format for a connection?) The patch fixes problems with simple values like '2 hours', '2 days' etc. It seems to me you tested it only on the complex ones. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 06:16 Message: Logged In: YES user_id=8500 I have just commited a patch to PgSQL.py that will fix the problem with theinterval parsing. Ondrej, Can you confirm that it corrects the poblem you were having. Thanks. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 15:27 Message: Logged In: YES user_id=8500 Try this: In psql insert '1 year 3 week 3 day ago'. Retrieve the value from the table using psql. Retrieve the value using pyPgSQL. It's broken. Also, can you or your friend submit a bug report about the problem and the change to ISO needed to make it work? Thanks. BTW: I will be commiting a fix for the interval problem today. ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-13 10:03 Message: Logged In: YES user_id=88611 BTW: There is a problem with DateTime type in Postgres 7.3 too. 7.2.3 works OK, but a friend reported that in 7.3 he had to modify the mx.DateTime.ISO . I think you should test it on this version too. As for the 'interval', 7.2.3 can eat postgres output correctly, I had only a problem with the conversion python->postgres. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 08:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-19 21:11:26
|
Bugs item #653044, was opened at 2002-12-13 01:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open Resolution: Fixed Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-19 22:11 Message: Logged In: YES user_id=88611 Apply the attached patch and it will be perfect !! (I have just upgraded to 7.3 and IMO my friend does not have set the date format to ISO. Isn't there some kind of 'SET DATEFORMAT TO ISO' or something like that in Postgres to force this format for a connection?) The patch fixes problems with simple values like '2 hours', '2 days' etc. It seems to me you tested it only on the complex ones. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 06:16 Message: Logged In: YES user_id=8500 I have just commited a patch to PgSQL.py that will fix the problem with theinterval parsing. Ondrej, Can you confirm that it corrects the poblem you were having. Thanks. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 15:27 Message: Logged In: YES user_id=8500 Try this: In psql insert '1 year 3 week 3 day ago'. Retrieve the value from the table using psql. Retrieve the value using pyPgSQL. It's broken. Also, can you or your friend submit a bug report about the problem and the change to ISO needed to make it work? Thanks. BTW: I will be commiting a fix for the interval problem today. ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-13 10:03 Message: Logged In: YES user_id=88611 BTW: There is a problem with DateTime type in Postgres 7.3 too. 7.2.3 works OK, but a friend reported that in 7.3 he had to modify the mx.DateTime.ISO . I think you should test it on this version too. As for the 'interval', 7.2.3 can eat postgres output correctly, I had only a problem with the conversion python->postgres. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 08:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-17 01:47:28
|
Patches item #653540, was opened at 2002-12-14 02:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Peticolas (jdavisp3) Assigned to: Nobody/Anonymous (nobody) Summary: Fix spelling in error messages. Initial Comment: Fix spelling in error messages. ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2002-12-17 02:47 Message: Logged In: YES user_id=163326 You need to check the checkbox "Check to Upload and Attach a File: [ ]" in order for the upload to work. It's a Sourceforge annoyance we can do nothing about :-( This happened to me several times before, even though I should know about this by now. ---------------------------------------------------------------------- Comment By: Dave Peticolas (jdavisp3) Date: 2002-12-14 22:36 Message: Logged In: YES user_id=9778 I'm not sure why uploading didn't work the first time, but it seems to have worked now. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 22:26 Message: Logged In: YES user_id=8500 Dave, The patch did not appear. Could you re-upload the patch. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 |
|
From: <no...@so...> - 2002-12-17 01:43:08
|
Bugs item #654957, was opened at 2002-12-17 02:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=654957&group_id=16528 Category: Documentation Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=654957&group_id=16528 |
|
From: <no...@so...> - 2002-12-14 21:36:21
|
Patches item #653540, was opened at 2002-12-14 01:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Peticolas (jdavisp3) Assigned to: Nobody/Anonymous (nobody) Summary: Fix spelling in error messages. Initial Comment: Fix spelling in error messages. ---------------------------------------------------------------------- >Comment By: Dave Peticolas (jdavisp3) Date: 2002-12-14 21:36 Message: Logged In: YES user_id=9778 I'm not sure why uploading didn't work the first time, but it seems to have worked now. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 21:26 Message: Logged In: YES user_id=8500 Dave, The patch did not appear. Could you re-upload the patch. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 |
|
From: <no...@so...> - 2002-12-14 21:26:01
|
Patches item #653540, was opened at 2002-12-13 20:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Peticolas (jdavisp3) Assigned to: Nobody/Anonymous (nobody) Summary: Fix spelling in error messages. Initial Comment: Fix spelling in error messages. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 16:26 Message: Logged In: YES user_id=8500 Dave, The patch did not appear. Could you re-upload the patch. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 |
|
From: <no...@so...> - 2002-12-14 05:16:43
|
Bugs item #653044, was opened at 2002-12-12 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open >Resolution: Fixed Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-12-14 00:16 Message: Logged In: YES user_id=8500 I have just commited a patch to PgSQL.py that will fix the problem with theinterval parsing. Ondrej, Can you confirm that it corrects the poblem you were having. Thanks. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 09:27 Message: Logged In: YES user_id=8500 Try this: In psql insert '1 year 3 week 3 day ago'. Retrieve the value from the table using psql. Retrieve the value using pyPgSQL. It's broken. Also, can you or your friend submit a bug report about the problem and the change to ISO needed to make it work? Thanks. BTW: I will be commiting a fix for the interval problem today. ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-13 04:03 Message: Logged In: YES user_id=88611 BTW: There is a problem with DateTime type in Postgres 7.3 too. 7.2.3 works OK, but a friend reported that in 7.3 he had to modify the mx.DateTime.ISO . I think you should test it on this version too. As for the 'interval', 7.2.3 can eat postgres output correctly, I had only a problem with the conversion python->postgres. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 02:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-14 04:48:56
|
Bugs item #653543, was opened at 2002-12-13 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653543&group_id=16528 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Peticolas (jdavisp3) >Assigned to: Billy G. Allie (ballie01) Summary: PgNumeric str problems Initial Comment: It looks like the newest version may have fixed this, but with 2.3-beta1-1, I get the following: >>> from pyPgSQL import PgSQL >>> x = PgSQL.PgNumeric ('-0.01', prec=15, scale=2) >>> x <PgNumeric instance - precision: 15 scale: 2 value: 0.-1 Note the '0.-1' representation. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 23:48 Message: Logged In: YES user_id=8500 Yes, This problem has been fixed in pyPgSQL 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653543&group_id=16528 |
|
From: <no...@so...> - 2002-12-14 01:03:00
|
Bugs item #653543, was opened at 2002-12-14 01:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653543&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Peticolas (jdavisp3) Assigned to: Nobody/Anonymous (nobody) Summary: PgNumeric str problems Initial Comment: It looks like the newest version may have fixed this, but with 2.3-beta1-1, I get the following: >>> from pyPgSQL import PgSQL >>> x = PgSQL.PgNumeric ('-0.01', prec=15, scale=2) >>> x <PgNumeric instance - precision: 15 scale: 2 value: 0.-1 Note the '0.-1' representation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653543&group_id=16528 |
|
From: <no...@so...> - 2002-12-14 01:01:04
|
Patches item #653540, was opened at 2002-12-14 01:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Peticolas (jdavisp3) Assigned to: Nobody/Anonymous (nobody) Summary: Fix spelling in error messages. Initial Comment: Fix spelling in error messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=653540&group_id=16528 |
|
From: <no...@so...> - 2002-12-13 14:27:15
|
Bugs item #653044, was opened at 2002-12-12 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 09:27 Message: Logged In: YES user_id=8500 Try this: In psql insert '1 year 3 week 3 day ago'. Retrieve the value from the table using psql. Retrieve the value using pyPgSQL. It's broken. Also, can you or your friend submit a bug report about the problem and the change to ISO needed to make it work? Thanks. BTW: I will be commiting a fix for the interval problem today. ---------------------------------------------------------------------- Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-13 04:03 Message: Logged In: YES user_id=88611 BTW: There is a problem with DateTime type in Postgres 7.3 too. 7.2.3 works OK, but a friend reported that in 7.3 he had to modify the mx.DateTime.ISO . I think you should test it on this version too. As for the 'interval', 7.2.3 can eat postgres output correctly, I had only a problem with the conversion python->postgres. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 02:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-13 09:04:01
|
Bugs item #653044, was opened at 2002-12-13 01:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Ondrej Palkovsky (ondrap) Date: 2002-12-13 10:03 Message: Logged In: YES user_id=88611 BTW: There is a problem with DateTime type in Postgres 7.3 too. 7.2.3 works OK, but a friend reported that in 7.3 he had to modify the mx.DateTime.ISO . I think you should test it on this version too. As for the 'interval', 7.2.3 can eat postgres output correctly, I had only a problem with the conversion python->postgres. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 08:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-13 07:16:17
|
Bugs item #653044, was opened at 2002-12-12 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) >Assigned to: Billy G. Allie (ballie01) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-12-13 02:16 Message: Logged In: YES user_id=8500 Ondrej, The underlying problem is an incompatibility of the formats used for intervals in PostgreSQL and DateTimeDeltas in mx. In your example, the 2:00:00:00.00 would have to be cast as '2 days 00:00:00.00' for PostgreSQL to accepts. There is also a problem with intervals > 1 day begin returns from PostgreSQL. The returned string can't be parsed by mx.DateTime.DateTimeDeltaFromString. I am working on a fix for the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-13 00:24:18
|
Bugs item #653044, was opened at 2002-12-13 01:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Nobody/Anonymous (nobody) Summary: DateTimeDelta does not work if >= 1 day Initial Comment: I think it is self-describing. It works for Delta up to 1 day though. The following works: c.execute("insert into test values (cast(%s as interval))",(t.seconds,)) so I guess something like: if isinstance(value,DateTime.DateTimeDeltaType): return 'cast(%s as interval)' % value.seconds in the quotation function would do it. Problem reproduction: ondra2=> create table test (a interval); CREATE ondra2=> \q ondra@linux:~$ python >>> from pyPgSQL import PgSQL >>> a = PgSQL.connect('::ondra2') >>> c = a.cursor() >>> from mx import DateTime >>> t = DateTime.Parser.TimeDeltaFromString('2 days') >>> t <DateTimeDelta object for '2:00:00:00.00' at 82aba40> >>> c.execute("insert into test values (%s)",(t,)) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 2671, in execute raise OperationalError, msg libpq.OperationalError: ERROR: Bad interval external representation '2:00:00:00.00' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=653044&group_id=16528 |
|
From: <no...@so...> - 2002-12-01 05:26:29
|
Bugs item #611979, was opened at 2002-09-20 01:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611979&group_id=16528 Category: None Group: None >Status: Pending Resolution: Postponed Priority: 2 Submitted By: Nobody/Anonymous (nobody) Assigned to: Billy G. Allie (ballie01) Summary: CREATE DATABASE impossible? Initial Comment: It appears that the current code-base makes a create-database call impossible. Basically, the call can't happen within a transaction, so the default operation of wrapping everything in a transaction prevents the operation from working. I'm new to the project, but this would seem to be a minimal workaround: #378 re_CREATEDB = re.compile('[\s]*CREATE[\s]+DATABASE[\s]', re.I) #2518 _badQuery = re_CREATEDB.search(query) or ( (self.conn.version < 70100) and \ (re_DRT.search(query) or re_DRI.search(query) ) ) However, that doesn't address any other potential calls that need a non-transactional framework. Not sure how you'd want to do this in the general case (probably another method would be required). Enjoy, and thanks for the module, Mike ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-20 22:31 Message: Logged In: YES user_id=8500 At least the re_DRT and re_DRI checks. These are only needed for PostgreSQL versions less then 7.1, so they can definitely go in pyPgSQL 3.0. They can go in future versions of 2.x if we decide to drop support for versions of PostgreSQL erlier than 7.1. It would sure simplify the logic of that section of code :-) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-10-20 17:26 Message: Logged In: YES user_id=163326 I'd say keep it as it is for now, mainly because I don't feel like implementing this and testing it with PostgreSQL 7.0 through 7.3 for the next release. Billy, your suggestion would be fine with me. Does this mean we could then remove the existing checks for DDL statements and just add an according note to the docs? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-10-18 20:22 Message: Logged In: YES user_id=8500 With later versions of PostgreSQL, the number of things that have to be performed outside of a transaction has decreased. I would think that setting autocommit to 1 on the connection would be an acceptable solution for thoses operations that have to be outside of a transaction.. Your thoughts on this? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-20 01:30 Message: Logged In: YES user_id=163326 I'm not entirely sure what to do about this. You can (temporarily) set autocommit=1 to work around this: from pyPgSQL import PgSQL con = PgSQL.connect() con.autocommit = 1 cursor = con.cursor() cursor.execute("create database foo") con.close() ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2002-09-20 01:12 Message: Logged In: YES user_id=34901 Sorry, this report was from me, just forgot to log in first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=611979&group_id=16528 |
|
From: <no...@so...> - 2002-12-01 05:24:41
|
Bugs item #645830, was opened at 2002-11-29 15:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=645830&group_id=16528 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Ondrej Palkovsky (ondrap) Assigned to: Billy G. Allie (ballie01) Summary: DateTime for postgres 7.2.3 Initial Comment: I have tried to access postgres 7.2.3 'datetime' (timestamp without time zone) type and always received a string from pgsql. I had to add type '1114' to the DBApiTypeObject DATETIME definition. I didn't find such constant in libpq so I guess it would need to be added there too. ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2002-12-01 00:24 Message: Logged In: YES user_id=8500 This is fixed in CVS and will be in the pyPgSQL 2.3 release. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2002-11-30 00:43 Message: Logged In: YES user_id=8500 7.2.3 brought into being a new type (TIMESTAMPTZOID) that didn't get put into pyPgSQL. It also changed the OID used for TIMESTAMP. I will be fixing tis problem and adding support for reference cursors shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=645830&group_id=16528 |
1 message has been excluded from this view by a project administrator.
