aboutsummaryrefslogtreecommitdiff
path: root/jimregexp.c
diff options
context:
space:
mode:
authoraf123 <jimdevel@hummypkg.org.uk>2012-11-29 10:26:14 +1000
committerSteve Bennett <steveb@workware.net.au>2012-11-29 10:30:15 +1000
commitfe63bcdba4b63372a0aa18e1444cfdbc8621a881 (patch)
tree21080e5eabe25434b2b578ec02300f6833492b85 /jimregexp.c
parent446c4faa6a6cda3c43ab68df168b3eeec67274b6 (diff)
downloadjimtcl-fe63bcdba4b63372a0aa18e1444cfdbc8621a881.zip
jimtcl-fe63bcdba4b63372a0aa18e1444cfdbc8621a881.tar.gz
jimtcl-fe63bcdba4b63372a0aa18e1444cfdbc8621a881.tar.bz2
Use sqlite3_prepare_v2()
When I'm working with SQLite3 databases in Jim, I find that I occasionally get a 'schema has changed' error so I end up using catch to detect the error and try the query again. Here's a quick patch to change the SQLite3 extension to use the sqlite3_prepare_v2() API function instead of sqlite3_prepare() - trivial but the _v2() function has a number of benefits and everyone should have a new enough SQLite3 library to support it. Please can you consider it for inclusion? See - http://www.sqlite.org/c3ref/prepare.html The benefit I'm specifically interested in is: With the _v2() variant, "If the database schema changes, instead of returning SQLITE_SCHEMA as it always used to do, sqlite3_step() will automatically recompile the SQL statement and try to run it again."
Diffstat (limited to 'jimregexp.c')
0 files changed, 0 insertions, 0 deletions