> > > DELETE sqlite_master WHERE type='f';
> >
> > Will all the btree pages orphaned at rootpage for these rows
> > not be recyclable until you run a full VACUUM?
> But if you delete the record for a regular table or index from
> the sqlite_master table using the "writable_schema" backdoor,
> you have just corrupted the database. In some cases a VACUUM
> will fix this corruption, in some cases not.
The following question is purely for curiosity's sake - I don't
advocate doing this... I just want to get a better understanding
of the sqlite3 file format.
Let's assume the most trivial case - a table without indexes of
any kind (implicit or explicit). Just arguing from a point of view
of the sqlite3 file format, if the row for the table/btree is deleted
in sqlite_master and the freelist is not updated, I can't see the
database being corrupted. The orphaned pages will not be reused until
VACUUM, and will needlessly occupy space on the disk, but they don't
seem to affect the other tables' and indexes' btree pages. In this
scenario, won't the new pages of other btrees avoid these orphaned
pages altogether?
I appreciate that should you run pragma integrity_check you'll see
something like this:
*** in database main ***
Page 2 is never used
but that's not corruption, per se, it's just space inefficiency, is
it not?
____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
