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...> - 2012-08-30 13:06:58
|
Bugs item #3563300, was opened at 2012-08-30 06:06 Message generated for change (Tracker Item Submitted) made by pai1ripe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=3563300&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andriy Pylypenko (pai1ripe) Assigned to: Nobody/Anonymous (nobody) Summary: Quoting doesn't work with PostgreSQL 9 Initial Comment: Hello, I'm using the pyPgSQL for quite a while, but recently I faced a trouble after migration to PostgreSQL 9. I found out that newly stored strings in the database are corrupted. After investigation I've created a patch which fixes the issue. Let me explain the problem. The pyPgSQL library uses backslash escaped strings when using parameter binding. Lets use as an example the string: 'Here is a newline: \n'. The PostgreSQL server has a special notation for backslash escaped strings, so the above string should be written with the E prefix: E'Here is a newline: \n'. If the E prefix is omitted then the PostgreSQL 9 sees it as 'Here is a newline: \\n' string, so the string actually two caracters - backslash and 'n' instead of a single newline character. Before the version 9 the PostgreSQL just warned about use of an incorrect notation and processed the string as a backslash escaped string anyway. The PostgreSQL 9 has changed this behavior and the E prefix is now mandatory. Taking into account that in pyPgSQL all the strings are forcibly casted to backslash escaped format during parameter binding, it is safe to always use the E prefix. This fixes the bug when working with PostgreSQL 9. It is also safe for earlier versions of the PostgreSQL, as this notation is recognized by them. Please see the attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=3563300&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2010-04-20 00:48:24
|
Bugs item #2508810, was opened at 2009-01-15 13:00 Message generated for change (Comment added) made by doobs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508810&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: PgVersion checks too restrictive Initial Comment: I was able to compile libpq for PG-8.3 on Vista, and build pyPgSQL-2.5.1. Then I got: File "c:\Python25\lib\site-packages\pyPgSQL\PgSQL.py", line 2210, in connect return Connection(connInfo, client_encoding, unicode_results) File "c:\Python25\lib\site-packages\pyPgSQL\PgSQL.py", line 2365, in __init__ raise DatabaseError, m libpq.DatabaseError: Invalid format for PgVersion construction. The "Invalid format for PgVersion?" problem is a simple code fix. pyPgSQL's pgversion.c basically calls: postgres=# select version(); version ----------------------------------------------------- PostgreSQL 8.3.5, compiled by Visual C++ build 1400 ...but expects the result to always be of the form: "PostgreSQL M.m.p on ...", and mine doesn't follow that form. Commenting out some of the version parsing code fixes it: PyErr_SetString(PyExc_ValueError, "Invalid format for PgVersion construction."); token = pg_strtok_r(s, " \t", &save_ptr); if (strcmp(token, "PostgreSQL") != 0) goto new_error; vstr = pg_strtok_r((char *)NULL, " \t", &save_ptr); token = pg_strtok_r((char *)NULL, " \t", &save_ptr); /* if (strcmp(token, "on") != 0) goto new_error; */ Those last two lines are what I commented out. ---------------------------------------------------------------------- Comment By: Doug du Boulay (doobs) Date: 2010-04-20 09:48 Message: forgot to say version string: PostgreSQL 8.3.6, compiled by Visual C++ build 1400 ---------------------------------------------------------------------- Comment By: Doug du Boulay (doobs) Date: 2010-04-20 09:31 Message: Yes indeed. I too just encountered this "Invalid format for PgVersion?" problem while connecting to a PostgreSQL 8.3 server on a Windows XP box. PyPgSQL used to work fine connecting to PostgreSQL 8.2 (specifically, python-pgsql 2.5.1-2ubuntu3 "A Python DB-API 2.0 interface to PostgreSQL") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508810&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2010-04-20 00:31:43
|
Bugs item #2508810, was opened at 2009-01-15 13:00 Message generated for change (Comment added) made by doobs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508810&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: PgVersion checks too restrictive Initial Comment: I was able to compile libpq for PG-8.3 on Vista, and build pyPgSQL-2.5.1. Then I got: File "c:\Python25\lib\site-packages\pyPgSQL\PgSQL.py", line 2210, in connect return Connection(connInfo, client_encoding, unicode_results) File "c:\Python25\lib\site-packages\pyPgSQL\PgSQL.py", line 2365, in __init__ raise DatabaseError, m libpq.DatabaseError: Invalid format for PgVersion construction. The "Invalid format for PgVersion?" problem is a simple code fix. pyPgSQL's pgversion.c basically calls: postgres=# select version(); version ----------------------------------------------------- PostgreSQL 8.3.5, compiled by Visual C++ build 1400 ...but expects the result to always be of the form: "PostgreSQL M.m.p on ...", and mine doesn't follow that form. Commenting out some of the version parsing code fixes it: PyErr_SetString(PyExc_ValueError, "Invalid format for PgVersion construction."); token = pg_strtok_r(s, " \t", &save_ptr); if (strcmp(token, "PostgreSQL") != 0) goto new_error; vstr = pg_strtok_r((char *)NULL, " \t", &save_ptr); token = pg_strtok_r((char *)NULL, " \t", &save_ptr); /* if (strcmp(token, "on") != 0) goto new_error; */ Those last two lines are what I commented out. ---------------------------------------------------------------------- Comment By: Doug du Boulay (doobs) Date: 2010-04-20 09:31 Message: Yes indeed. I too just encountered this "Invalid format for PgVersion?" problem while connecting to a PostgreSQL 8.3 server on a Windows XP box. PyPgSQL used to work fine connecting to PostgreSQL 8.2 (specifically, python-pgsql 2.5.1-2ubuntu3 "A Python DB-API 2.0 interface to PostgreSQL") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508810&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2009-11-13 19:15:27
|
Bugs item #2897405, was opened at 2009-11-13 14:15 Message generated for change (Tracker Item Submitted) made by edwardfaulkner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2897405&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Edward Faulkner (edwardfaulkner) Assigned to: Nobody/Anonymous (nobody) Summary: PgConnection.flush fails to handle nonblocking writes Initial Comment: PgConnection.flush appears to misunderstand how to use the underlying PQflush function. When PQflush returns 1, this is not an error. The 1 should be returned to the caller of PgConnection.flush, so the caller knows whether to call flush again. 1 means "call again when the socket is writable." 0 means "no more data to write". -1 means error, and only in this case should PgConnection.flush throw an exception. This is necessary for any application that wants to write big statements in a nonblocking way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2897405&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2009-07-01 15:26:40
|
Bugs item #2815270, was opened at 2009-07-01 17:26 Message generated for change (Tracker Item Submitted) made by guidod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2815270&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido U. Draheim (guidod) Assigned to: Nobody/Anonymous (nobody) Summary: web frontpage refers to discontinued KRUD distro Initial Comment: The frontpage at http://pypgsql.sourceforge.net/ says "pyPgSQL is available as a Redhat RPM as part of the KRUD distribution that builds on Redhat. These RPMs are now also available for downloading at the project page." However KRUD was discontinued in 2006. http://distrowatch.com/table.php?distribution=krud http://www.tummy.com/Products/krud/ (dated 2005) A good hint on usual RPM source to use would still be quite helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2815270&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2009-01-15 04:00:16
|
Bugs item #2508810, was opened at 2009-01-15 04:00 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=2508810&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: PgVersion checks too restrictive Initial Comment: I was able to compile libpq for PG-8.3 on Vista, and build pyPgSQL-2.5.1. Then I got: File "c:\Python25\lib\site-packages\pyPgSQL\PgSQL.py", line 2210, in connect return Connection(connInfo, client_encoding, unicode_results) File "c:\Python25\lib\site-packages\pyPgSQL\PgSQL.py", line 2365, in __init__ raise DatabaseError, m libpq.DatabaseError: Invalid format for PgVersion construction. The "Invalid format for PgVersion?" problem is a simple code fix. pyPgSQL's pgversion.c basically calls: postgres=# select version(); version ----------------------------------------------------- PostgreSQL 8.3.5, compiled by Visual C++ build 1400 ...but expects the result to always be of the form: "PostgreSQL M.m.p on ...", and mine doesn't follow that form. Commenting out some of the version parsing code fixes it: PyErr_SetString(PyExc_ValueError, "Invalid format for PgVersion construction."); token = pg_strtok_r(s, " \t", &save_ptr); if (strcmp(token, "PostgreSQL") != 0) goto new_error; vstr = pg_strtok_r((char *)NULL, " \t", &save_ptr); token = pg_strtok_r((char *)NULL, " \t", &save_ptr); /* if (strcmp(token, "on") != 0) goto new_error; */ Those last two lines are what I commented out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508810&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2009-01-14 22:43:30
|
Bugs item #2508263, was opened at 2009-01-14 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508263&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py needs secur32.lib for win32 Initial Comment: I compiled a new libpq from postgresql-8.3.5 today on Vista, and then received the following error while trying to build pyPgSQL against it: C:\download\Python\pyPgSQL-2.5.1>python setup.py build ... C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\download\Postgres\postgresql-8.3.5\src\interfaces\libpq\Release /LIBPATH:C:\Python26\libs /LIBPATH :C:\Python26\PCbuild libpq.lib wsock32.lib advapi32.lib shell32.lib /EXPORT:initlibpq build\temp.win32-2.6\Release\libpqmodule.obj build\temp.win32-2.6\Release\pgboolean.obj build\temp.win32-2.6\Release\pgint2object.obj build\temp.win32-2.6\Release\pgint8object.obj build\temp.win32-2.6\Release\pgversion.obj build\temp.win32-2.6\Release\pglargeobject.obj build\temp.win32-2.6\Release\pgnotify.obj build\temp.win32-2.6\Release\pgconnection.obj build\temp.win32-2.6\Release\pgresult.obj build\temp.win32-2.6\Release\pymemstrdup.obj build\temp.win32-2.6\Release\port/strtoll.obj build\temp.win32-2.6\Release\port/strtoull.obj build\temp.win32-2.6\Release\port/strtok.obj /OUT:build\lib.win32-2.6\pyPgSQL\libpq\libpq.pyd /IMPLIB:build\temp.win32-2.6\Release\libpq.lib /MANIFESTFILE:build\temp.win32-2.6\ Release\libpq.pyd.manifest Creating library build\temp.win32-2.6\Release\libpq.lib and object build\temp.win32-2.6\Release\libpq.exp libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol __imp__DeleteSecurityContext@4 referenced in function _closePGconn libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol __imp__FreeCredentialsHandle@4 referenced in function _closePGconn libpq.lib(fe-auth.obj) : error LNK2019: unresolved external symbol _FreeContextBuffer@4 referenced in function _pg_SSPI_continue libpq.lib(fe-auth.obj) : error LNK2019: unresolved external symbol _InitializeSecurityContextA@48 referenced in function _pg_SSPI_continue libpq.lib(fe-auth.obj) : error LNK2019: unresolved external symbol _AcquireCredentialsHandleA@36 referenced in function _pg_SSPI_startup build\lib.win32-2.6\pyPgSQL\libpq\libpq.pyd : fatal error LNK1120: 5 unresolved externals error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1120 This occurs because 'secur32.lib' is not present. The fix is simple: add 'secur32' to setup.py: elif sys.platform == "win32": ## library_dirs[0] = library_dirs[0] + "/ms" optional_libs = ["libpq", "wsock32", "advapi32", "shell32", "secur32"] modname="pyPgSQL.libpq.libpq" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=2508263&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2008-04-10 04:53:22
|
Patches item #1939119, was opened at 2008-04-10 13:53 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=1939119&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Choe, Cheng-Dae (whitekid) Assigned to: Nobody/Anonymous (nobody) Summary: fix for PgBytea quote uses PQespcaeByteaConn Initial Comment: PgBytes quote the value using internal implementation. But. The bytea escaping make different by connection property. and PostgreSQL 8.3.1 make some modify on escaping bytea escaping method In release note 8.3.1 "Make encode(bytea, 'escape') convert all high-bit-set byte values into \nnn octal escape sequences (Tom) " Becase of above thing. current implementation was make some error on Bytea escaping. This patch add libPQquoteByteaConn(libpqmodule.c) and use this method to encode Bytea type. If you use this patch. pleas use PgBytea type with connection like as PgBytea(value, conn) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1939119&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2008-03-24 22:00:35
|
Bugs item #1924687, was opened at 2008-03-24 22:00 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=1924687&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgConnection Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Brewer (aminusfu) Assigned to: Nobody/Anonymous (nobody) Summary: callproc result set not retrievable Initial Comment: The Cursor.callproc method in pyPgSQL (at least up to version 1.5) has two problems. First, it takes *args instead of a single args parameter, which is contrary to the DBAPI spec and most other implementations of it. Second, it calls 'select proc(args)', which does not allow fetchall() to retrieve its return value. Therefore, this patches pyPgSQL.Cursor.callproc to take a single args param, and to execute 'select * from proc(args)', which allows fetchall() to work properly. It'd be nice if a future version of pyPgSQL used the "*" form of the call. from pyPgSQL import PgSQL as pgsql if not hasattr(pgsql.Cursor, "_old_callproc"): def callproc2(self, proc, args): """ Call a stored procedure with a fetchable return value. Note that this takes a single args attribute instead of *args. """ return self._old_callproc(" * from " + proc, *args) pgsql.Cursor._old_callproc = pgsql.Cursor.callproc pgsql.Cursor.callproc = callproc2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1924687&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2008-03-11 09:37:30
|
Bugs item #1911732, was opened at 2008-03-11 10:37 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=1911732&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pietro Bernardi (bpietro2) Assigned to: Nobody/Anonymous (nobody) Summary: wrong indentation (aka unknown PEP 8) Initial Comment: >From PEP 8 - Style guide: Indentation Use 4 spaces per indentation level. For really old code that you don't want to mess up, you can continue to use 8-space tabs. Tabs or Spaces? Never mix tabs and spaces. The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only. Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively. Once more: Never mix tabs and spaces! PgSQL.py (2.5.1) use: tabs for even indentation levels and zero o more tabs + four spaces for odd levels. Seems good if you have 8 spaces tab setting in your editor, otherwise leads in mess code. Regards, Pietro ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1911732&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2008-03-11 09:14:59
|
Bugs item #1911722, was opened at 2008-03-11 10:14 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=1911722&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pietro Bernardi (bpietro2) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode value can't be converted? Initial Comment: All versions of PgSQL (including last one, 2.5.1) have this omission: Unlike StringType, UnicodeType can't be converted to PgNumeric; see example: >>> from pyPgSQL import PgSQL >>> a = '10.1' >>> b = PgSQL.PgNumeric(a) >>> b <PgNumeric instance - precision: 3 scale: 1 value: 10.1> >>> c = u'10.1' >>> d = PgSQL.PgNumeric(c) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py", line 1447, in __init__ raise TypeError, "value can not be converted to a PgNumeric." TypeError: value can not be converted to a PgNumeric. Almost all wxwidgets now return unicode value, which must be casted to string for conversion to PgNumeric. Simple patch can remedy it: PgSQL.py line 1469: elif type(value) in (FloatType, StringType): replace it with: elif type(value) in (FloatType, StringType, UnicodeType): Regards, Pietro ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1911722&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2008-03-09 14:40:00
|
Bugs item #1755777, was opened at 2007-07-18 00:56 Message generated for change (Comment added) made by bpietro2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1755777&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: PgNumeric += is strange Initial Comment: The augmented arithmetic operations on PgNumeric instances will update the object directly, instead of creating a new one. This leads to unexpected results such as: $ cat t.py from pyPgSQL.PgSQL import PgNumeric a = PgNumeric(1.0) b = a b += 1 print a, b $ python t.py 2.0 2.0 Here we see b is incremented, but both a and b are changed, because the __iadd__ method updates b in place. Call me naive, but I would expect "b += 1" to behave exactly like "b = b+1". Perhaps PgNumeric should allocate a new object if the old one has multiple references? I'm not sure, but the current behavior is not intuitive, and leads to hard-to-find bugs. ---------------------------------------------------------------------- Comment By: Pietro Bernardi (bpietro2) Date: 2008-03-09 15:40 Message: Logged In: YES user_id=2014513 Originator: NO IMHO you are right, it's worse, this bug affects not only '+='. See this: >>> ZERO = PgSQL.PgNumeric('0') >>> a = ZERO; b = ZERO; b = b + 1; c = ZERO >>> print ZERO,a,b,c 0 0 1 0 >>> a = ZERO; b = ZERO; b += 1; c = ZERO >>> print ZERO,a,b,c 1 1 1 1 >>> ZERO = PgSQL.PgNumeric('0') >>> a = ZERO; b = ZERO; b = b - 1; c = ZERO >>> print ZERO,a,b,c 0 0 -1 0 >>> a = ZERO; b = ZERO; b -= 1; c = ZERO >>> print ZERO,a,b,c -1 -1 -1 -1 >>> TWO = PgSQL.PgNumeric('2') >>> a = TWO; b = TWO; b = b * 3; c = TWO >>> print TWO,a,b,c 2 2 6 2 >>> a = TWO; b = TWO; b *= 3; c = TWO >>> print TWO,a,b,c 6 6 6 6 >>> TWO = PgSQL.PgNumeric('2') >>> a = TWO; b = TWO; b = b / 2; c = TWO >>> print TWO,a,b,c 2 2 1 2 >>> a = TWO; b = TWO; b /= 2; c = TWO >>> print TWO,a,b,c 1 1 1 1 Regards, Pietro ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1755777&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-19 14:25:58
|
Bugs item #1854028, was opened at 2007-12-19 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1854028&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Luca Falavigna (dktrkranz) Assigned to: Nobody/Anonymous (nobody) Summary: typo in pyPgSQL/PgSQL.py Initial Comment: Typo in pyPgSQL/PgSQL.py, line 999, causes this error: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/pyPgSQL/test.py", line 5, in <module> res = cur.fetchall() File "/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py", line 3247, in fetchall _list.append(self.__fetchOneRow()) File "/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py", line 2814, in __fetchOneRow _r.getvalue(self._idx_, _i))) File "/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py", line 890, in typecast return self.handleArray(colinfo, _list) File "/usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py", line 999, in handleArray if _fvt != PG_INTERVAL: NameError: global name '_fvt' is not defined Replacing _fvt with _ftv fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1854028&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-18 21:20:24
|
Bugs item #1853235, was opened at 2007-12-18 11:10 Message generated for change (Comment added) made by vvinet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1853235&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Vincent Vinet (vvinet) Assigned to: Nobody/Anonymous (nobody) Summary: Interval/DateTime Arrays Failure Initial Comment: I get a very odd error when trying to execute queries returning arrays of datetime or interval objects. Here is sample code to reproduce the error: ==================================== import PgSQL conn = PgSQL.connect()#supply your credentials and your server cur = conn.cursor() cur.execute("SELECT ARRAY[now()]") res = cur.fetchall() cur.execute("SELECT ARRAY[now() + '1 hour' - now()]") res = cur.fetchall() ==================================== Now, both of these queries spit out the same error: --------------------------------------------------------------------------- <type 'exceptions.NameError'> Traceback (most recent call last) /usr/lib/python2.5/site-packages/pyPgSQL/<ipython console> in <module>() /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in fetchall(self) 3245 # to the list of results. 3246 while self._idx_ < self._rows_: -> 3247 _list.append(self.__fetchOneRow()) 3248 3249 # Fetch the remaining results from the PostgreSQL portal. /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in __fetchOneRow(self) 2812 for _i in range(self.res.nfields): 2813 _j.append(_c.typecast(self.description[_i], -> 2814 _r.getvalue(self._idx_, _i))) 2815 2816 self._idx_ = self._idx_ + 1 /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in typecast(self, colinfo, value) 888 # Convert string representation of the array into PgArray object. 889 _list = self.parseArray(value) --> 890 return self.handleArray(colinfo, _list) 891 892 if _ftv == PG_INT2: /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in handleArray(self, colinfo, lst) 997 lst[_i] = PgInt2(lst[_i]) 998 elif _ftv == DATETIME: --> 999 if _fvt != PG_INTERVAL: 1000 if lst[_i] in ('infinity', '+infinity', '-infinity'): 1001 fake_infinity = '9999-12-13 23:59:59' # fake infinity <type 'exceptions.NameError'>: global name '_fvt' is not defined ... I don't really understant how this error is possible, but it still happens This was tested using python2.5 --version Python 2.5.1 python-pgsql version 2.5.1-2build1 The same code works fine under 2.4.3 ---------------------------------------------------------------------- >Comment By: Vincent Vinet (vvinet) Date: 2007-12-18 16:20 Message: Logged In: YES user_id=1867373 Originator: YES Posted on launchpad https://bugs.launchpad.net/ubuntu/+source/python-pgsql/+bug/177268/ ---------------------------------------------------------------------- Comment By: Vincent Vinet (vvinet) Date: 2007-12-18 11:19 Message: Logged In: YES user_id=1867373 Originator: YES I will attempt to find the first version that has this bug, and will refile this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1853235&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-18 16:23:00
|
Patches item #1853244, was opened at 2007-12-18 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=316528&aid=1853244&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vincent Vinet (vvinet) Assigned to: Nobody/Anonymous (nobody) Summary: Use December 31, 9999 instead of December 13 for infinite Initial Comment: When faced with infinity as a value for datetimes, the current code replaces them with the maximum value for python's datetime type. I guess a type made it into the code, as the date currently used is December 13, 9999... a simple sed -i PgSQL.py -e "s:9999-12-13:9999-12-31:g" Fixes the two occurences, as shown by a subsequent diff -u PgSQL.py.bak PgSQL.py --- PgSQL.py.bak 2007-12-18 11:11:12.000000000 -0500 +++ PgSQL.py 2007-12-18 11:11:36.000000000 -0500 @@ -928,7 +928,7 @@ elif _ftv == DATETIME: if type(value) is DateTimeType: if value in ('infinity', '+infinity', '-infinity'): - fake_infinity = '9999-12-13 23:59:59' # fake infinity + fake_infinity = '9999-12-31 23:59:59' # fake infinity if value[0] == '-': value = '-' + fake_infinity else: @@ -998,7 +998,7 @@ elif _ftv == DATETIME: if _fvt != PG_INTERVAL: if lst[_i] in ('infinity', '+infinity', '-infinity'): - fake_infinity = '9999-12-13 23:59:59' # fake infinity + fake_infinity = '9999-12-31 23:59:59' # fake infinity if lst[_i][0] == '-': lst[_i] = '-' + fake_infinity else: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1853244&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-18 16:19:31
|
Bugs item #1853235, was opened at 2007-12-18 11:10 Message generated for change (Comment added) made by vvinet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1853235&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Vincent Vinet (vvinet) Assigned to: Nobody/Anonymous (nobody) Summary: Interval/DateTime Arrays Failure Initial Comment: I get a very odd error when trying to execute queries returning arrays of datetime or interval objects. Here is sample code to reproduce the error: ==================================== import PgSQL conn = PgSQL.connect()#supply your credentials and your server cur = conn.cursor() cur.execute("SELECT ARRAY[now()]") res = cur.fetchall() cur.execute("SELECT ARRAY[now() + '1 hour' - now()]") res = cur.fetchall() ==================================== Now, both of these queries spit out the same error: --------------------------------------------------------------------------- <type 'exceptions.NameError'> Traceback (most recent call last) /usr/lib/python2.5/site-packages/pyPgSQL/<ipython console> in <module>() /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in fetchall(self) 3245 # to the list of results. 3246 while self._idx_ < self._rows_: -> 3247 _list.append(self.__fetchOneRow()) 3248 3249 # Fetch the remaining results from the PostgreSQL portal. /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in __fetchOneRow(self) 2812 for _i in range(self.res.nfields): 2813 _j.append(_c.typecast(self.description[_i], -> 2814 _r.getvalue(self._idx_, _i))) 2815 2816 self._idx_ = self._idx_ + 1 /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in typecast(self, colinfo, value) 888 # Convert string representation of the array into PgArray object. 889 _list = self.parseArray(value) --> 890 return self.handleArray(colinfo, _list) 891 892 if _ftv == PG_INT2: /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in handleArray(self, colinfo, lst) 997 lst[_i] = PgInt2(lst[_i]) 998 elif _ftv == DATETIME: --> 999 if _fvt != PG_INTERVAL: 1000 if lst[_i] in ('infinity', '+infinity', '-infinity'): 1001 fake_infinity = '9999-12-13 23:59:59' # fake infinity <type 'exceptions.NameError'>: global name '_fvt' is not defined ... I don't really understant how this error is possible, but it still happens This was tested using python2.5 --version Python 2.5.1 python-pgsql version 2.5.1-2build1 The same code works fine under 2.4.3 ---------------------------------------------------------------------- >Comment By: Vincent Vinet (vvinet) Date: 2007-12-18 11:19 Message: Logged In: YES user_id=1867373 Originator: YES I will attempt to find the first version that has this bug, and will refile this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1853235&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-18 16:10:31
|
Bugs item #1853235, was opened at 2007-12-18 11:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1853235&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vincent Vinet (vvinet) Assigned to: Nobody/Anonymous (nobody) Summary: Interval/DateTime Arrays Failure Initial Comment: I get a very odd error when trying to execute queries returning arrays of datetime or interval objects. Here is sample code to reproduce the error: ==================================== import PgSQL conn = PgSQL.connect()#supply your credentials and your server cur = conn.cursor() cur.execute("SELECT ARRAY[now()]") res = cur.fetchall() cur.execute("SELECT ARRAY[now() + '1 hour' - now()]") res = cur.fetchall() ==================================== Now, both of these queries spit out the same error: --------------------------------------------------------------------------- <type 'exceptions.NameError'> Traceback (most recent call last) /usr/lib/python2.5/site-packages/pyPgSQL/<ipython console> in <module>() /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in fetchall(self) 3245 # to the list of results. 3246 while self._idx_ < self._rows_: -> 3247 _list.append(self.__fetchOneRow()) 3248 3249 # Fetch the remaining results from the PostgreSQL portal. /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in __fetchOneRow(self) 2812 for _i in range(self.res.nfields): 2813 _j.append(_c.typecast(self.description[_i], -> 2814 _r.getvalue(self._idx_, _i))) 2815 2816 self._idx_ = self._idx_ + 1 /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in typecast(self, colinfo, value) 888 # Convert string representation of the array into PgArray object. 889 _list = self.parseArray(value) --> 890 return self.handleArray(colinfo, _list) 891 892 if _ftv == PG_INT2: /usr/lib/python2.5/site-packages/pyPgSQL/PgSQL.py in handleArray(self, colinfo, lst) 997 lst[_i] = PgInt2(lst[_i]) 998 elif _ftv == DATETIME: --> 999 if _fvt != PG_INTERVAL: 1000 if lst[_i] in ('infinity', '+infinity', '-infinity'): 1001 fake_infinity = '9999-12-13 23:59:59' # fake infinity <type 'exceptions.NameError'>: global name '_fvt' is not defined ... I don't really understant how this error is possible, but it still happens This was tested using python2.5 --version Python 2.5.1 python-pgsql version 2.5.1-2build1 The same code works fine under 2.4.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1853235&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-10 05:00:05
|
Patches item #1847662, was opened at 2007-12-10 00:00 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=1847662&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthew Grosso (mgrosso) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug 1847659 connection to 8.3beta3 fails on vers Initial Comment: changes the srtok_r delimiter to accept beta ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1847662&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-12-10 04:52:54
|
Bugs item #1847659, was opened at 2007-12-09 23:52 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=1847659&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgConnection Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthew Grosso (mgrosso) Assigned to: Nobody/Anonymous (nobody) Summary: connection to 8.3beta3 fails on version info Initial Comment: >>> c=pyPgSQL.PgSQL.connect(user='mgrosso') Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2211, in connect return Connection(connInfo, client_encoding, unicode_results) File "/usr/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 2331, in __init__ raise DatabaseError, m libpq.DatabaseError: Ivalid format for PgVersion construction. >>> c its fixed by this change $ diff -u pyPgSQL-2.5.1 pyPgSQL-2.5.1-betafix Only in pyPgSQL-2.5.1-betafix: build Common subdirectories: pyPgSQL-2.5.1/examples and pyPgSQL-2.5.1-betafix/examples diff -u pyPgSQL-2.5.1/pgversion.c pyPgSQL-2.5.1-betafix/pgversion.c --- pyPgSQL-2.5.1/pgversion.c 2006-06-02 07:27:45.000000000 -0700 +++ pyPgSQL-2.5.1-betafix/pgversion.c 2007-12-09 20:22:32.000000000 -0800 @@ -293,12 +293,12 @@ if (parseToken(token, &major)) goto new_error; - token = pg_strtok_r((char *)NULL, ".", &save_ptr); + token = pg_strtok_r((char *)NULL, ".-beta", &save_ptr); if ((token != (char *)NULL) && (*token != '\0') && (parseToken(token, &minor))) goto new_error; - token = pg_strtok_r((char *)NULL, ".-", &save_ptr); + token = pg_strtok_r((char *)NULL, ".-beta", &save_ptr); if ((token != (char *)NULL) && (*token != '\0') && (parseToken(token, &patch))) { Common subdirectories: pyPgSQL-2.5.1/port and pyPgSQL-2.5.1-betafix/port Common subdirectories: pyPgSQL-2.5.1/pyPgSQL and pyPgSQL-2.5.1-betafix/pyPgSQL Common subdirectories: pyPgSQL-2.5.1/test and pyPgSQL-2.5.1-betafix/test $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1847659&group_id=16528 |
|
From: Kai <ka...@sc...> - 2007-11-01 14:58:08
|
I guess this fixes a bug?
=2D-- pyPgSQL-2.5.1/pyPgSQL/PgSQL.py.orig 2007-11-01 15:48:35.000000000 +01=
00
+++ pyPgSQL-2.5.1/pyPgSQL/PgSQL.py 2007-11-01 15:49:14.000000000 +0100
@@ -936,7 +936,7 @@
return value
else:
if _ftv =3D=3D PG_INTERVAL:
=2D return self.interval2RelativeDateTime(value)
+ return self.interval2DateTimeDelta(value)
elif _ftv =3D=3D PG_TIME:
return DateTime.Parser.TimeFromString(value)
else:
Cheers
Kai
=2D-=20
Kai R. Bj=F8rnstad
Domain leader, Infrastructure
Phone: +47 92 44 81 11
Mob: +47 99 57 79 11
=46ax: +47 22 23 36 66
ka...@sc...
Scali AS
Nydalsveien 36
0484 Oslo
NORWAY
Scali - www.scali.com
Higher Performance Computing
|
|
From: Billy G. A. <bil...@de...> - 2007-10-19 07:23:31
|
Billy G. Allie wrote: > SourceForge.net wrote: >> Bugs item #1755777, was opened at 2007-07-17 18:56 >> 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=1755777&group_id=16528 >> >> >> Please note that this message will contain a full copy of the comment >> thread, >> including the initial issue submission, for this request, >> not just the latest update. >> Category: PgNumeric >> Group: None >> Status: Open >> Resolution: None >> Priority: 5 >> Private: No >> Submitted By: Ken Lalonde (kenlalonde) >> Assigned to: Nobody/Anonymous (nobody) >> Summary: PgNumeric += is strange >> >> Initial Comment: >> The augmented arithmetic operations on PgNumeric instances will >> update the object directly, >> instead of creating a new one. >> This leads to unexpected results such as: >> >> $ cat t.py >> from pyPgSQL.PgSQL import PgNumeric >> a = PgNumeric(1.0) >> b = a >> b += 1 >> print a, b >> $ python t.py >> 2.0 2.0 >> >> Here we see b is incremented, but both a and b >> are changed, because the __iadd__ method updates >> b in place. >> >> Call me naive, but I would expect "b += 1" >> to behave exactly like "b = b+1". >> >> Perhaps PgNumeric should allocate a new object >> if the old one has multiple references? >> I'm not sure, but the current behavior >> is not intuitive, and leads to hard-to-find bugs. > It's in the nature of the in-place operators when they apply to > objects. The statement "b +=1" adds one to the existing object > referenced by > "b". Since a is also a reference to the same object, it also displays > the new result. The statement "b = b + 1" creates a new object with > the value of "b + 1" and puts a reference to it into b. > > Ok, that explains the problem. The question is how to fix it. The > solution as you pointed out would be to create a new PgNumeric object > and place a reference to it into "b", but I don't know if it is > possible to do that. Any thoughts on the problem would be appreciated. > > -- > Bill Allie > > It turned out to be easier to fix then I thought. Attached is a patch to fix the problem. -- Bill Allie. |
|
From: Billy G. A. <bil...@de...> - 2007-10-19 07:01:25
|
SourceForge.net wrote: > Bugs item #1755777, was opened at 2007-07-17 18:56 > 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=1755777&group_id=16528 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: PgNumeric > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Ken Lalonde (kenlalonde) > Assigned to: Nobody/Anonymous (nobody) > Summary: PgNumeric += is strange > > Initial Comment: > The augmented arithmetic operations on PgNumeric instances will update the object directly, > instead of creating a new one. > This leads to unexpected results such as: > > $ cat t.py > from pyPgSQL.PgSQL import PgNumeric > a = PgNumeric(1.0) > b = a > b += 1 > print a, b > $ python t.py > 2.0 2.0 > > Here we see b is incremented, but both a and b > are changed, because the __iadd__ method updates > b in place. > > Call me naive, but I would expect "b += 1" > to behave exactly like "b = b+1". > > Perhaps PgNumeric should allocate a new object > if the old one has multiple references? > I'm not sure, but the current behavior > is not intuitive, and leads to hard-to-find bugs. > It's in the nature of the in-place operators when they apply to objects. The statement "b +=1" adds one to the existing object referenced by "b". Since a is also a reference to the same object, it also displays the new result. The statement "b = b + 1" creates a new object with the value of "b + 1" and puts a reference to it into b. Ok, that explains the problem. The question is how to fix it. The solution as you pointed out would be to create a new PgNumeric object and place a reference to it into "b", but I don't know if it is possible to do that. Any thoughts on the problem would be appreciated. -- Bill Allie |
|
From: SourceForge.net <no...@so...> - 2007-08-27 06:54:28
|
Bugs item #800801, was opened at 2003-09-05 02:17 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=800801&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgSQL Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Mike C. Fletcher (mcfletch) >Assigned to: Nobody/Anonymous (nobody) Summary: Precision lost from mxDateTime during queries Initial Comment: When working with PostgreSQL timestamps, round-trips to/from Python wind up losing data (the least-significant digits of the timestamp, 1000ths of seconds and less). Result is that timestamps which include 1000ths of seconds cannot be queried from Python using mxDateTime values. PyPgSQL should likely be using code something like the following to format an mxDateTime value for a timestamp: new.Format( '%Y-%m-%d %H:%M:%%s' )%( new.second, ) or new.Format( '%Y-%m-%d %H:%M:%%r' )%( new.second, ) (difference being use of 'r' format, which will do as much as possible to be sure that the resulting string is capable of exactly producing the original format). To illustrate: from pytable import dbspecifier, sqlquery spec = dbspecifier.DBSpecifier( dbdriver='PyPgSQL', database='cinemon', host='localhost', user='cinemon', password='xxxx' ) driver, connection = spec.connect() ((new,),) = sqlquery.SQLQuery( sql = """SELECT MAX( archive_ts ) from log_modem;""" )( connection ) print 'new', repr(new) print 'seconds', new.second records = sqlquery.SQLQuery( sql = """SELECT * from log_modem where archive_ts = %%(new)s;""" )( connection, new=new ).fetchall() print records # is an empty list because of truncation... V:\cinemon>err_date_truncation.py new <DateTime object for '2003-09-04 19:50:16.30' at 93a820> seconds 16.297984 [] ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2006-06-22 11:40 Message: Logged In: YES user_id=163326 Thanks. I'll try to integrate your proposal for 2.5.2. Sigh. Better late than never. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=800801&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-08-27 06:53:19
|
Patches item #1511984, was opened at 2006-06-25 03:34 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1511984&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Clarence (clarence1126) >Assigned to: Nobody/Anonymous (nobody) Summary: Add savepoint method to Connection Initial Comment: Adds savepoint() and release() methods to Connection, and modifies rollback() to optionally rollback only to the savepoint. Deals only with one, unnamed from the user's point of view, savepoint. ---------------------------------------------------------------------- Comment By: Markus Schiltknecht (schiltknecht) Date: 2006-10-06 12:43 Message: Logged In: YES user_id=1614584 I'm trying to upload an update to the patch. ---------------------------------------------------------------------- Comment By: Clarence (clarence1126) Date: 2006-06-26 22:31 Message: Logged In: YES user_id=1537139 Oh, you have to check that silly box or it ignores your upload :( Hopefully, here's the patch without whitespace issues ---------------------------------------------------------------------- Comment By: Clarence (clarence1126) Date: 2006-06-26 22:25 Message: Logged In: YES user_id=1537139 Beats me how SourceForge works. Here's the file again. ---------------------------------------------------------------------- Comment By: Clarence (clarence1126) Date: 2006-06-26 22:24 Message: Logged In: YES user_id=1537139 Here is a patch without whitespace issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316528&aid=1511984&group_id=16528 |
|
From: SourceForge.net <no...@so...> - 2007-07-17 22:56:09
|
Bugs item #1755777, was opened at 2007-07-17 18:56 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=1755777&group_id=16528 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PgNumeric Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: PgNumeric += is strange Initial Comment: The augmented arithmetic operations on PgNumeric instances will update the object directly, instead of creating a new one. This leads to unexpected results such as: $ cat t.py from pyPgSQL.PgSQL import PgNumeric a = PgNumeric(1.0) b = a b += 1 print a, b $ python t.py 2.0 2.0 Here we see b is incremented, but both a and b are changed, because the __iadd__ method updates b in place. Call me naive, but I would expect "b += 1" to behave exactly like "b = b+1". Perhaps PgNumeric should allocate a new object if the old one has multiple references? I'm not sure, but the current behavior is not intuitive, and leads to hard-to-find bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116528&aid=1755777&group_id=16528 |
1 message has been excluded from this view by a project administrator.
