On Mon, Feb 8, 2010 at 9:26 PM, Roger Binns <rog...@rogerbinns.com> wrote:
> Virtual tables do not directly have any storage - they are just a row in > sqlite_master. > > The implementation may do something. For example FTS3 creates 3 real tables > behind the scenes. Virtual tables that map to a CSV file generally do not > delete the CSV file when the virtual table is dropped. > > What this means is that for some cases it is perfectly harmless to drop the > virtual table as it has no side effects. In other cases (eg FTS3) then you > would lose its behind the scenes tables. I am using FTS3, so in my case I cannot just drop the table. Even if the virtual table is just a row in sqlite_master, doesn't it still makes sense to support IF NOT EXISTS? Whether it's storage-backed or not, won't attempting to create it a second time always give a "table already exists" error? Also, what is the recommended way to build sqlite3 if you want to make changes to parse.y, given that using the complete source tree tarball is heavily recommended against (in favour of the amalgamation, which only contains the generated code)? Thanks, Hamish _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users