They can be valid chars in Python 3. Or maybe not? In which case Python
will throw an exception, but that's fine.
Fix regression introduced fixing #211
For library end users, there is no need to install tests alongside the
package itself. This keeps the tests available for development without
adding extra packages to user's site-packages directory. Reduces the
size of the installed package. Avoids accidental execution of test code
by an installed package.
Per the functions documentation, this argument is not supported on
Python 3. Skip it during tests.
> :param unicode: if `!True`, keys and values returned from the database
> will be `!unicode` instead of `!str`. The option is not available on
> Python 3
Work towards moving tests outside of the installed package.
The tests relied on Python2 relative import semantics. Python3 changed
import semantics to always search sys.path by default. To import using a
relative path it must have a leading dot.
Forward compatible with newer Pythons.
Works towards the goal of moving tests outside of the installed package.
For more information, see PEP-328:
https://www.python.org/dev/peps/pep-0328/
The json module is available in all Python versions supported by
psycopg2. No need to check for its presence when executing tests.
Should have been included with d58844e548
but was missed.
Not compatible with Python3. Makes the code more forward compatible with
modern Pythons.
In Python2, it was an alternative syntax for octal.
$ python3
>>> 01
File "<stdin>", line 1
01
^
SyntaxError: invalid token
There is no need to import testutils.unittest instead of simply
unittest. They are simple aliases. Use system unittest to be more
regular, consistent as well as idiomatic with the wider Python
community.
The decimal module is available on all Python versions supported by
psycopg2. It has been available since Python 2.4. No need to catch an
ImportError.
https://docs.python.org/2/library/decimal.html
namedtuple is available on all Python versions supported by psycopg2. It
was first introduced in Python 2.6. Can remove all workarounds and
special documentation.
The syntax "except Exception, exc:" is deprecated. All Python versions
supported by psycopg2 support the newer, modern syntax. Forward
compatible with future Python versions.
It was registered as side effect of an excessive definition that got
cleaned up in 338dbe70a6.
Looking at other removed redundant type oids, this was the only one
missing from the `string_types` map.
Close#578.
Should close#558, but I'm curious to know if a number is returned
for interval < 1 day too (which wouldn't trigger the overflow, but will
finish parsing with part=0).
I'll be honest: I lucked out, I didn't think about this combination. But
maybe sheer luck, maybe using common code paths, it just works. Let's
make it stays so.
From the DB-API (https://www.python.org/dev/peps/pep-0249/):
OperationalError
Exception raised for errors that are related to the database's
operation and not necessarily under the control of the programmer,
e.g. an unexpected disconnect occurs, [...]
Additionally, psycopg2 was inconsistent, at least in the async case:
depending on how the "connection closed" error was reported from the
kernel to libpq, it would sometimes raise OperationalError and
sometimes DatabaseError. Now it always raises OperationalError.
There's a race condition that only seems to happen over Unix-domain
sockets. Sometimes, the closed socket is reported by the kernel to
libpq like this (captured with strace):
sendto(3, "Q\0\0\0\34select pg_backend_pid()\0", 29, MSG_NOSIGNAL, NULL, 0) = 29
recvfrom(3, "E\0\0\0mSFATAL\0C57P01\0Mterminating "..., 16384, 0, NULL, NULL) = 110
recvfrom(3, 0x12d0330, 16384, 0, 0, 0) = -1 ECONNRESET (Connection reset by peer)
That is, psycopg2/libpq sees no error when sending the first query
after the connection is closed, but gets an error reading the result.
In that case, everything worked fine.
But sometimes, the error manifests like this:
sendto(3, "Q\0\0\0\34select pg_backend_pid()\0", 29, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)
recvfrom(3, "E\0\0\0mSFATAL\0C57P01\0Mterminating "..., 16384, 0, NULL, NULL) = 110
recvfrom(3, "", 16274, 0, NULL, NULL) = 0
recvfrom(3, "", 16274, 0, NULL, NULL) = 0
i.e. libpq received an error when sending the query. This manifests as
a slightly different exception from a slightly different place. More
importantly, in this case connection.closed is left at 0 rather than
being set to 2, and that is the bug I'm fixing here.
Note that we see almost identical behaviour for sync and async
connections, and the fixes are the same. So I added extremely similar
test cases.
Finally, there is still a bug here: for async connections, we
sometimes raise DatabaseError (incorrect) and sometimes raise
OperationalError (correct). Will fix that next.
(almost... except for micros rounding)
While this is probably an improvement on the previous implementation,
I am largely waving a dead chicken at windows, which keeps failing to
pass the seconds overflow test. If it doesn't pass now either I'll start
blaming Python's timedelta.
