Documentation Source Text

Check-in [84efe9e646]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix documentation typos reported on the mailing list.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 84efe9e646ab955aef9afa50a6e63c7917d555bd
User & Date: drh 2014-05-27 10:31:29
Context
2014-05-27
15:31
Add the "X in (?)" optimization to the change log. check-in: 487c297731 user: drh tags: trunk
10:31
Fix documentation typos reported on the mailing list. check-in: 84efe9e646 user: drh tags: trunk
2014-05-26
23:18
Fix Win32 to say Win64 for 64-bit DLLs on the download page. check-in: 3638ded7d1 user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/changes.in.

    28     28   <li>Added the [sqlite3_rtree_query_callback()] interface to [R-Tree extension]
    29     29   <li>Added the [SQLITE_IOCAP_IMMUTABLE] bit to the set of bits that can be returned by
    30     30       the xDeviceCharacteristics method of a [VFS].
    31     31   <li>Added new [URI query parameters] "nolock" and "immutable".
    32     32   <li>Use less memory by not remembering CHECK constraints on read-only
    33     33       database connections.
    34     34   <li>Enable the [or-connected-terms | OR optimization] for [WITHOUT ROWID] tables.
    35         -query<p><b>Bug Fixes:</b>
           35  +<p><b>Bug Fixes:</b>
    36     36   <li>OFFSET clause ignored on queries without a FROM clause.
    37     37       Ticket [http://www.sqlite.org/src/info/07d6a0453d | 07d6a0453d]
    38     38   <li>Assertion fault on queries involving expressions of the form
    39     39       "x IN (?)".  Ticket [http://www.sqlite.org/src/info/e39d032577|e39d032577].
    40     40   <li>Incorrect column datatype reported.
    41     41       Ticket [http://www.sqlite.org/src/info/a8a0d2996a | a8a0d2996a]
    42     42   <li>Duplicate row returned on a query against a table with more than

Changes to pages/fts3.in.

   630    630       More than one NEAR operator may appear in a single query. In this case each
   631    631       pair of terms or phrases separated by a NEAR operator must appear within the
   632    632       specified proximity of each other in the document. Using the same table and
   633    633       data as in the block of examples above:
   634    634   </ul>
   635    635   
   636    636   <codeblock> 
   637         - <i>-- The following query selects documents that contains an instance of the term </i>
          637  +  <i>-- The following query selects documents that contains an instance of the term </i>
   638    638     <i>-- "sqlite" separated by two or fewer terms from an instance of the term "acid",</i>
   639    639     <i>-- which is in turn separated by two or fewer terms from an instance of the term</i>
   640         -  <i>-- "relational". As it happens, the only document in table docs satisfies this criteria.</i>
          640  +  <i>-- "relational".</i>
   641    641     SELECT * FROM docs WHERE docs MATCH 'sqlite NEAR/2 acid NEAR/2 relational';
   642    642   
   643    643     <i>-- This query matches no documents. There is an instance of the term "sqlite" with</i>
   644    644     <i>-- sufficient proximity to an instance of "acid" but it is not sufficiently close</i>
   645    645     <i>-- to an instance of the term "relational".</i>
   646    646     SELECT * FROM docs WHERE docs MATCH 'acid NEAR/2 sqlite NEAR/2 relational';
   647    647   </codeblock>
................................................................................
  2124   2124   
  2125   2125   <codeblock>
  2126   2126       <i>-- Create a table that uses the unicode61 tokenizer, but considers "."</i>
  2127   2127       <i>-- and "=" characters to be part of tokens, and capital "X" characters to</i>
  2128   2128       <i>-- function as separators.</i>
  2129   2129       CREATE VIRTUAL TABLE txt3 USING fts4(tokenize=unicode61 "tokenchars=.=" "separators=X");
  2130   2130   
  2131         -    <i>-- Create a tables that considers space characters (codepoint 32) to be</i>
         2131  +    <i>-- Create a table that considers space characters (codepoint 32) to be</i>
  2132   2132       <i>-- a token character</i>
  2133   2133       CREATE VIRTUAL TABLE txt4 USING fts4(tokenize=unicode61 "tokenchars= ");
  2134   2134   </codeblock>
  2135   2135   
  2136   2136   <p>
  2137   2137     If a character specified as part of the argument to "tokenchars=" is considered
  2138   2138     to be a token character by default, it is ignored. This is true even if it has

Changes to pages/queryplanner.in.

   316    316   <p>
   317    317   A multi-column index follows the same pattern as a single-column index;
   318    318   the indexed columns are added in front of the rowid.  The only difference
   319    319   is that now multiple columns are added.  The left-most column is the
   320    320   primary key used for ordering the rows in the index.  The second column is
   321    321   used to break ties in the left-most column.  If there were a third column,
   322    322   it would be used to break ties for the first two columns.  And so forth for
   323         -as many columns as their are in the index.  Because rowid is guaranteed
          323  +all columns in the index.  Because rowid is guaranteed
   324    324   to be unique, every row of the index will be unique even if all of the
   325    325   content columns for two rows are the same.  That case does not happen
   326    326   in our sample data, but there is one case (fruit='Orange') where there
   327    327   is a tie on the first column which must be broken by the second column.
   328    328   </p>
   329    329   
   330    330   <p>
................................................................................
   676    676   so that the states will appear in descending order.
   677    677   </p>
   678    678   
   679    679   <tcl>hd_fragment {partialsort} {partial sorting by index}</tcl>
   680    680   <h3>3.2 Partial Sorting Using An Index</h3>
   681    681   
   682    682   <p>
   683         -Sometimes only part of an ORDER BY clause an be satisfied using indexes.
          683  +Sometimes only part of an ORDER BY clause can be satisfied using indexes.
   684    684   Consider, for example, the following query:
   685    685   </p>
   686    686   
   687    687   <tcl>
   688    688   code {SELECT * FROM fruitforsale ORDER BY fruit, price}
   689    689   </tcl>
   690    690   

Changes to pages/rtree.in.

   376    376     void *pContext
   377    377   );
   378    378   </pre></blockquote>
   379    379   
   380    380   <p>The sqlite3_rtree_query_callback() became available with SQLite
   381    381   [version 3.8.5] and is the preferred interface.
   382    382   The sqlite3_rtree_geometry_callback() is an older and less flexible
   383         -interface that is supported for backwards compatiblity.
          383  +interface that is supported for backwards compatibility.
   384    384   
   385    385   <p>^A call to one of the above APIs creates a new SQL function named by the
   386    386   second parameter (zQueryFunc or zGeom).  ^When that SQL function appears
   387    387   on the right-hand side of the MATCH operator and the left-hand side of the
   388    388   MATCH operator is any column in the R*Tree virtual table, then the callback 
   389    389   defined by the third argument (xQueryFunc or xGeom) is invoked to determine
   390    390   if a particular object or subtree overlaps the desired region.
................................................................................
   421    421   
   422    422   <p>The sqlite3_rtree_geometry structure that the first argument to the
   423    423   xGeom callback points to has a structure shown below.  ^The exact same
   424    424   sqlite3_rtree_geometry
   425    425   structure is used for every callback for same MATCH operator in the same
   426    426   query.  ^The contents of the sqlite3_rtree_geometry
   427    427   structure are initialized by SQLite but are
   428         -not subsequently modifed.  The callback is free to make changes to the
          428  +not subsequently modified.  The callback is free to make changes to the
   429    429   pUser and xDelUser elements of the structure if desired.
   430    430   
   431    431   <blockquote><pre>
   432    432   typedef struct sqlite3_rtree_geometry sqlite3_rtree_geometry;
   433    433   struct sqlite3_rtree_geometry {
   434    434     void *pContext;                 /* Copy of pContext passed to s_r_g_c() */
   435    435     int nParam;                     /* Size of array aParam */
................................................................................
   460    460   <p>^The xGeom callback always does a depth-first search of the r-tree.
   461    461   
   462    462   <tcl>hd_fragment xquery {xQueryFunc R*Tree callback} {sqlite3_rtree_query_callback}
   463    463   </tcl>
   464    464   <h3>6.2 The New xQueryFunc Callback</h3>
   465    465   
   466    466   <p>The newer xQueryFunc callback receives more information from the r-tree
   467         -query engine on each call, and it send more information back to the query engine
          467  +query engine on each call, and it sends more information back to the query engine
   468    468   before it returns.
   469    469   To help keep the interface manageable, the xQueryFunc callback sends and receives
   470    470   information from the query engine as fields in the
   471    471   sqlite3_rtree_query_info structure:
   472    472   
   473    473   <blockquote><pre>
   474    474   struct sqlite3_rtree_query_info {
................................................................................
   554    554   the priority queue at each level.
   555    555   
   556    556   <h3>6.3 Additional Considerations for Custom Queries</h3>
   557    557   
   558    558   <p>
   559    559   ^The MATCH operator of a custom R*Tree query function must be a top-level
   560    560   AND-connected term of the WHERE clause, or else it will not be usable
   561         -by the R*Tree query optimizer and the query will not be runable.
          561  +by the R*Tree query optimizer and the query will not be runnable.
   562    562   ^If the MATCH operator is connected to other terms of the WHERE clause 
   563    563   via an OR operator, for example, the query will fail with an error.
   564    564   
   565    565   <p>
   566    566   ^Two or more MATCH operators are allowed in the same WHERE clause, as long
   567    567   as they are connected by AND operators.  However,
   568    568   the R*Tree query engine only contains a single priority queue.  ^The priority
   569    569   assigned to each node in the search is the lowest priority returned by any
   570    570   of the MATCH operators.

Changes to pages/uri.in.

    40     40   ^If URI filenames are recognized when the database connection is originally
    41     41   opened, then URI filenames will also be recognized on [ATTACH] statements.
    42     42   ^Similarly, if URI filenames are not recognized when the database connection
    43     43   is first opened, they will not be recognized by [ATTACH].
    44     44   </p>
    45     45   
    46     46   <p>
    47         -Since SQLite always interprets any filename that does not begins 
           47  +Since SQLite always interprets any filename that does not begin
    48     48   with "<tt>file:</tt>"
    49     49   as an ordinary filename regardless of the URI setting, and because it is
    50     50   very unusual to have an actual file begin with "<tt>file:</tt>", 
    51     51   it is safe for most applications to enable URI processing even if URI 
    52     52   filenames are not currently being used.
    53     53   </p>
    54     54   
................................................................................
   134    134   <li>Prepend the "<tt>file:</tt>" scheme.
   135    135   </ol>
   136    136   
   137    137   <h2>3.2 Query String</h2>
   138    138   
   139    139   <p>^A URI filename can optionally be followed by a query string.
   140    140   ^The query string consists of text following the first "<tt>?</tt>"
   141         -character but excluding the optional fragment that begins with with
          141  +character but excluding the optional fragment that begins with
   142    142   "<tt>#</tt>".  ^The query string is divided into key/value pairs.
   143    143   We usually refer to these key/value pairs as "query parameters".
   144    144   ^Key/value pairs are separated by a single "<tt>&amp;</tt>" character.
   145    145   ^The key comes first and is separated from the value by a single
   146    146   "<tt>=</tt>" character.
   147    147   ^Both key and value may contain <b>%HH</b> escape sequences.</p>
   148    148   
................................................................................
   150    150   ^The text of query parameters is appended to the filename argument of
   151    151   the xOpen method of the [VFS].
   152    152   ^Any %HH escape sequences in the query parameters are resolved prior to
   153    153   being appended to the xOpen filename.
   154    154   ^A single zero-byte separates the xOpen filename argument from the key of
   155    155   the first query parameters, each key and value, and each subsequent key
   156    156   from the prior value.
   157         -^The list of query parameters parameters appended to the xOpen filename
          157  +^The list of query parameters appended to the xOpen filename
   158    158   is terminated by a single zero-length key.
   159    159   Note that the value of a query parameter can be an empty string.
   160    160   </p>
   161    161   
   162    162   <tcl>hd_fragment coreqp *coreqp {standard query parameters} {URI query parameters} \
   163    163       {query parameters with special meaning to SQLite}</tcl>
   164    164   <h2>3.3 Recognized Query Parameters</h2>