[Python-checkins] r46962 - in python/trunk: Lib/sqlite3/test/hooks.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/connection.c

[Neal Norwitz]

I forgot to mention that all the builbots (even one on 3.1.3 or is
that my laptop) pass with the change I checked in.  probably rev
26964.

n
--

On 6/14/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> Can you take a look at my checkin?  It only added 2 lines and the
> tests pass after removing the version checks.  I don't know if there's
> a good reason to *not* do the fix I did.
>
> n
> --
>
> On 6/14/06, Gerhard Häring <gh at ghaering.de> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Anthony Baxter wrote:
> > > On Thursday 15 June 2006 08:28, gerhard.haering wrote:
> > >
> > >> - Added version checks in C code to make sure we don't trigger bugs
> > >> in older SQLite versions.
> > >> - Added version checks in test suite so that we don't execute tests
> > >> that we know will fail with older (buggy) SQLite versions.
> > >>
> > >> Now, all tests should run against all SQLite versions from 3.0.8
> > >> until 3.3.6 (latest one now). The sqlite3 module can be built
> > >> against all these SQLite versions and the sqlite3 module does its
> > >> best to not trigger bugs in SQLite, but using SQLite 3.3.3 or later
> > >> is recommended.
> > >
> > >> +void _sqlite3_result_error(sqlite3_context* ctx, const char*
> > >> errmsg, int len) +{
> > >> +    /* in older SQLite versions, calling sqlite3_result_error in
> > >> callbacks +     * triggers a bug in SQLite that leads either to
> > >> irritating results or +     * segfaults, depending on the SQLite
> > >> version */
> > >> +#if SQLITE_VERSION_NUMBER >= 3003003
> > >> +    sqlite3_result_error(ctx, errmsg, len);
> > >> +#endif
> > >
> > > Could this code at least set a generic error message, saying something
> > > like "Unknown SQLite error in callback (see documentation for
> > > explanation)" and have a note in the docs saying "SQLite older than
> > > 3.3.3 is buggy and can't give useful callback errors".
> >
> > That's not possible in a straightforward manner, because the natural way of
> > doing this requires a "sqlite3_result_error" that's not buggy :-/
> >
> > Otherwise I could probably go the long-workaround-way by storing a
> > reference to the Connection object in the SQLite context and then setting a
> > new variable char* callback_error on the Connection object in case.
> >
> > That requires a bit more testing than is possible before beta1 and I don't
> > like the idea of putting in a whole lot of extra code for working around
> > SQLite bugs.
> >
> > FWIW the old pysqlite code simply ignored any errors in callbacks in the
> > first place. And this is what we now still do for the old, buggy SQLite
> > versions.
> >
> > > Hm. Is the underlying sqlite3 version number even exported to Python?
> >
> > Yes, as sqlite_version and sqlite_version_info.
> >
> > - -- Gerhard
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.2 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFEkPa9dIO4ozGCH14RAmCzAKCFhf7e3jr9eF6MozmU1/z9jwXvZwCcCVDe
> > nJ/1FGUkDDh0aSU0zyG+aO4=
> > =S06c
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Python-checkins mailing list
> > Python-checkins at python.org
> > http://mail.python.org/mailman/listinfo/python-checkins
> >
>