SQLite CVSTrac

*** 107,121 ****
  
     CREATE TABLE vtabname USING c_module(arg-list);
  
! For example, suppose we have a table containing the content
! of email messages:
  
!    CREATE TABLE email(xto TEXT, xfrom TEXT, subj TEXT, body TEXT);
! 
! To create a full-text index on the subject and body of this
! table, one might do the following:
! 
!    CREATE VIEW emailfts ON email(subj,body) USING fulltextsearch1;
  
  The "fulltextsearch1" identifier is associated with a C-language
  module that is registered separately, in a manner similar to
--- 107,116 ----
  
     CREATE TABLE vtabname USING c_module(arg-list);
  
! For example, suppose we want to create a virtual table that
! will do full-text search on the content of email messages:
  
!    CREATE TABLE emailfts USING fulltextsearch1;
  
  The "fulltextsearch1" identifier is associated with a C-language
  module that is registered separately, in a manner similar to
***************
*** 126,131 ****
--- 121,172 ----
  full text search engine, such as what tokenizer and stemmer
  algorithms to use and whether or not token positional information
  should be stored in order to help with phrase queries.
+ 
+ In the fulltextsearch1 module, the columns of the virtual
+ table are fixed.  One can image a more sophisticated implementation
+ in which the columns are specified by arguments:
+ 
+    CREATE TABLE emailfts USING fts2(
+      docid INTEGER PRIMARY KEY,
+      subj TEXT INDEXED,
+      body TEXT INDEXED
+    );
+ 
+ The comma-separate arguments to the C-language module in a
+ virtual table create statement can be any arbitrary sequence
+ of tokens.  The arguments are passed into the module as a
+ array of strings, one string for each argument.  The module
+ is responsible for parsing the arguments.  In the example
+ above, we would expect the module to create a virtual table
+ containing three columns named docid, subj, and body.  We
+ further expect the virtual table to cause docid to be the
+ rowid and that subj and body are both columns that participate
+ in the full-text index.  In this example, the internal parser
+ in fts2 would interpret its arguments very much like a standard
+ SQL table declaration.
+ 
+ But arguments do not have to be interpreted this way.  The
+ arguments could be used to specify optional parameters.
+ Consider the following example:
+ 
+    CREATE TABLE emailfts3 USING fts3(
+      stemmer = porter,
+      retain content = off,
+      fast phrase searching = off
+    );
+ 
+ Here we have a example of a full-text search
+ engine that has fixed column names, but is configured to
+ select a different stemmer, to store only the index and not the
+ original text of the documents being indexed, and to use a slower
+ but more disk-space efficient algorithm for doing phrase searching.
+ 
+ All of the examples above are hypothetical.  They are intended to
+ show the flexibility of the virtual table mechanism.  An actual
+ full-text search virtual table might work differently from the
+ examples above.  The examples are intended to illustrate the
+ power and flexibility of virtual tables, not to serve as a
+ design spec for full-text search.
  
  The CREATE TABLE statements for virtual tables
  are stored in the SQLITE_MASTER table and are reread when a

sqlite - Virtual Tables