drh [Thu, 16 Aug 2007 04:30:38 +0000 (04:30 +0000)]
Half-way through a major refactoring of the memory allocation.
I have not even attempted to compile so I am certain there are
countless errors. (CVS 4231)
danielk1977 [Wed, 15 Aug 2007 17:08:46 +0000 (17:08 +0000)]
Modify the crash-recovery test code in test6.c for 3.5. Also change some other code to use the new sqlite3_io_methods interface. Lots of things are broken now. (CVS 4228)
drh [Mon, 13 Aug 2007 11:10:34 +0000 (11:10 +0000)]
Remove a memory allocation from sqlite3VdbeIOTraceSql(). This means that
when doing I/O tracing, the text of an SQL statement is truncated to the
first 1000 characters. But it also means tracing works in an out-of-memory
situation. (CVS 4210)
drh [Fri, 10 Aug 2007 23:54:16 +0000 (23:54 +0000)]
Fix the corruption problem of ticket #2565 as demonstrated by the test added
in (4204). There may yet be other instances of similar problems lurking in
the code. (CVS 4206)
shess [Fri, 10 Aug 2007 23:47:03 +0000 (23:47 +0000)]
Convert fts2 to use sqlite3_prepare_v2() to prevent certain logic
errors around SQLITE_SCHEMA handling. This also allows
sql_step_statement() and sql_step_leaf_statement() to be replaced with
sqlite3_step().
Also fix a logic error in flushPendingTerms() which was clearing the
term table in case of error. This was wrong in the face of
SQLITE_SCHEMA. Even though the change to sqlite3_prepare_v2() should
cause us not to see SQLITE_SCHEMA any longer, it was still a logic
error... (CVS 4205)
drh [Fri, 10 Aug 2007 16:41:08 +0000 (16:41 +0000)]
Add the --soft-heap-limit=N option to the test scripts. Set this value to
enforce a soft heap limit across all tests. This changes exposes several
new bugs. (CVS 4202)
drh [Wed, 8 Aug 2007 01:04:52 +0000 (01:04 +0000)]
Additional refinements on the amalgamation: Give a couple of constants
file scope and add the SQLITE_API prefix to some interfaces that need it.
Ticket #2554. (CVS 4199)
danielk1977 [Fri, 3 Aug 2007 07:33:08 +0000 (07:33 +0000)]
Avoid reloading the schema when an expired statement is finalized or reset.
This is only necessary when the in-memory schema does not match the file-system schema. (CVS 4194)
Fix ticket #2439: the FTS1 and FTS2 extensions use the non-standard,
unportable and highly deprecated <malloc.h> header on all platforms
except Apple Mac OS X. The <malloc.h> actually is never required on
any OS with an at least partly POSIX-conforming API as the malloc(3) &
friends functions officially live in <stdlib.h> since over 10 years.
Under some platform like FreeBSD the inclusion of <malloc.h> since a few
years even causes an "#error" and this way a build failure. So, just get
rid of the bad <malloc.h> usage in FTS1 and FTS2 extensions at all and
stick with <stdlib.h> there only. (CVS 4191)
"extern" declarations inside function bodies are not every compiler's
favorite, so move to global scope. Additionally, at least under Unix
environment use <unistd.h> to get the proper prototype instead of using
a K&R-style own declaration. (CVS 4190)
Get rid of the following compile-time warnings:
tool/mkkeywordhash.c:353: warning: array subscript has type 'char'
tool/mkkeywordhash.c:354: warning: array subscript has type 'char' (CVS 4189)
Fix a bug with explicit collation sequences attached to a column reference expression that is on the right-hand-side of a binary comparison operator. (CVS 4187)
Replicates http://www.sqlite.org/cvstrac/chngview?cn=4151 which
modified fts2:
Modify handling of SQLITE_SCHEMA in fts2 code. An SQLITE_SCHEMA error
may cause SQLite to reload the internal schema, deleting and
recreating v-table objects. So the sqlite3_vtab structure can be
deleted out from under a v-table implementation. (CVS 4183)
Apply change 4095 to fts1. Fix snippet generation when the left-most
column of an fts table is used in the MATCH clause. Fix for ticket
#2429. (CVS 4181)
Remove the comment in the documentation that says that incremental vacuum
mode is not persistent because as of 3.4.1 it is persistent. Ticket #2528. (CVS 4180)
Work around an AFP file system byte-range locking error caused by opening and closing a second file descriptor on the database file as RDWR which clears the exclusive byte-range lock and results in an fcntl error when the AFP locking code attempts to clear it afterwards. This error is caused by the test harness and isn't a flaw in the sqlite or its implementation of AFP file locking. (CVS 4172)
Add new APIs to the end of the sqlite3_apis structure in loadext.c, in order
to preserve backwards compatibility. Fix an incompatibility introduced
by (4108). (CVS 4168)
Modify handling of SQLITE_SCHEMA in fts2 code. An SQLITE_SCHEMA error may cause SQLite to reload the internal schema, deleting and recreating v-table objects. So the sqlite3_vtab structure can be deleted out from under a v-table implementation. (CVS 4151)
Remove an unnecessary temporary variable for clarity of presentation in
a loop that GCC 4.2.0 is miscompiling. Ticket #2469. GCC 4.2.0 miscompiles
this loop regardless of whether or not the temporary variable is used, but
by removing the variable, we hope to make it easier to explain the problem
to GCC maintainers. The error only appears if -ftree-vrp is used (which
is turned on by -O2). (CVS 4150)
Change OS/2 version of sqlite3Os2FullPathname() for cross-compiler compatibility:
- allocate zBuff on demand (restricted stack space on old compilers)
- 2 bytes in zDrive in include '\0'
- pass drive number to DosQueryCurrentDir() instead of 0 to make EMX work
- zFull does not need to be preallocated (CVS 4149)
drh [Wed, 27 Jun 2007 10:21:38 +0000 (10:21 +0000)]
Fix typo in comments of the sqlite.h.in header file - comments from which
documentation is automatically extracted and generated. Ticket #2468. (CVS 4139)
drh [Wed, 27 Jun 2007 00:08:39 +0000 (00:08 +0000)]
Update the FAQ to describe how moving sqlite3 handles across threads is
not safe with SQLITE_ENABLE_MEMORY_MANAGEMENT. Tickets #2357 and #2463. (CVS 4136)
drh [Tue, 26 Jun 2007 22:55:37 +0000 (22:55 +0000)]
Make sure the TCL bindings always use Tcl_GetWideIntFromObj() even if the
reported type is "int" because on x86-64 and "int" type is 64-bits.
Ticket #2465. (CVS 4135)