such as was shipped with Centos 5 and Mac OS X 10.4.
This bug was already fixed in issue14572 for 2.7 only and then it was
backported back from 3.3 in issue17073.
characters. This avoids the common case of something like 'NUMBER(10)' not
being parsed as 'NUMBER', like expected. Also corrected the docs about
converter names being case-sensitive. They aren't any longer.
merged into the 2.5 maintenance branch:
- self->statement was not checked while fetching data, which could
lead to crashes if you used the pysqlite API in unusual ways.
Closing the cursor and continuing to fetch data was enough.
- Converters are stored in a converters dictionary. The converter name
is uppercased first. The old upper-casing algorithm was wrong and
was replaced by a simple call to the Python string's upper() method
instead.
-Applied patch by Glyph Lefkowitz that fixes the problem with
subsequent SQLITE_SCHEMA errors.
- Improvement to the row type: rows can now be iterated over and have a keys()
method. This improves compatibility with both tuple and dict a lot.
- A bugfix for the subsecond resolution in timestamps.
- Corrected the way the flags PARSE_DECLTYPES and PARSE_COLNAMES are
checked for. Now they work as documented.
- gcc on Linux sucks. It exports all symbols by default in shared
libraries, so if symbols are not unique it can lead to problems with
symbol lookup. pysqlite used to crash under Apache when mod_cache
was enabled because both modules had the symbol cache_init. I fixed
this by applying the prefix pysqlite_ almost everywhere. Sigh.
of SQLite3 from 3.2.2 to 3.0.8, by providing an alternative to
sqlite3_transfer_bindings. setup.py also handles the common (in debian
and ubuntu, at least) case of a buggy sqlite3.h SQLITE_VERSION_NUMBER.
This is based on pysqlite2.1.3, and provides a DB-API interface in
the standard library. You'll need sqlite 3.2.2 or later to build
this - if you have an earlier version, the C extension module will
not be built.