Scott Hess wrote:
>Unfortunately, the reason fts2 couldn't be "fixed" was because you
>can't perform the necessary ALTER TABLE if the column you're adding is
>a primary key.
Sure, I was aware of this problem.
>Since the only alternative would be to build a new
>table and copy everything over,
Unfortunately, the reason fts2 couldn't be "fixed" was because you
can't perform the necessary ALTER TABLE if the column you're adding is
a primary key. Since the only alternative would be to build a new
table and copy everything over, it seemed more reasonable to just let
the app developer do
--- Ralf Junker <[EMAIL PROTECTED]> wrote:
> This one just came to my mind:
>
> CREATE TABLE (rowid INTEGER PRIMARY KEY, t TEXT);
>
> This promotes "rowid" to a visible column "rowid" which does not change
> during a VACUUM. "rowid"
> is already a reserved word in SQLite. Maybe this option is
This one just came to my mind:
CREATE TABLE (rowid INTEGER PRIMARY KEY, t TEXT);
This promotes "rowid" to a visible column "rowid" which does not change during
a VACUUM. "rowid" is already a reserved word in SQLite. Maybe this option is
even compatible to FTS2?
Ralf
>ext/fts3.c in the
ext/fts3.c in the current code fixes the fts2-vs-vacuum problem by
adding "docid INTEGER PRIMARY KEY" to the %_content table. This
becomes an alias for rowid, and thus causes vacuum to not renumber
rowids. It is safe to add that column because the other columns in
%_content are constructed such
5 matches
Mail list logo
