deleting all rows from an fts3 table would leave a bunch of index data
describing the terms of the original data, plus deletions of those
terms, perhaps with some amount of it merged together so the deletions
knocked out the originals. Even when all rows were deleted that
original data would hang out, though eventually it would mostly be
overwritten if new data contained the same set of terms. (CVS 5413)
FossilOrigin-Name: 8b872e426091d9ef108e52dbec0d968ed7452907
being able to write test script which verify that fts3 is internally
building indices in the expected way. Both new functions are only
defined if fts3.c is compiled with SQLITE_TEST defined, as when
building testfixture. These functions are not intended to be part of
the exposed fts3 API.
dump_terms() generates a TEXT result of all the terms in the index (or
a specified segment), sorted and joined with spaces.
dump_doclist() generates a TEXT representation of the doclist
associated with a given term in the index (or a specified segment). (CVS 5340)
FossilOrigin-Name: a48e3d95f7a656285e959cef595cbe6d53428ad9
as appropriate, in case the comments are ever again read by a pedantic
grammarian. Ticket #2840. (CVS 4629)
FossilOrigin-Name: 4e91a267febda572e7239f0f1cc66b3102558c36
linearly merged the doclists, so as the accumulated list got large,
things got slow (the M term, a fucntion of the number of documents in
the index). This change does pairwise merges until a single doclist
remains. A test search of 't*' against a database of RFC text
improves from 1m16s to 4.75s. (CVS 4599)
FossilOrigin-Name: feef1b15d645d638b4a05742f214b0445fa7e176
rowid, similar to how things work in SQLite tables with INTEGER
PRIMARY KEY. Add tests to verify operation. (CVS 4426)
FossilOrigin-Name: c8d2345200f9ece1af712543982097d0b6f348c7
alias to fix the rowid for documents, %_segments.blockid is an alias
to fix the rowid for segment blocks. Unit test for the problem. (CVS 4280)
FossilOrigin-Name: 6eb2d74a8cfce322930f05c97d4ec255f3711efb
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)
FossilOrigin-Name: 16730cb137eaf576b87cdc17913564c9c5c0ed82
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)
FossilOrigin-Name: 3f9a666143a8aafa0b1a5d56ec68f69f2b3d6a21
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)
FossilOrigin-Name: f9020cffda02923ef45979bb447ec2e232086ad5
