/ Check-in [799f5383]
Login

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

Overview
Comment:Documentation updates. (CVS 1946)
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:799f5383c0c72a74c7b29f9f40fc949f3248a499
User & Date: drh 2004-09-08 13:06:21
Context
2004-09-08
13:07
Add new APIs to sqlite3.def: sqlite3_bind_parameter_name and sqlite3_bind_parameter_index. (CVS 1947) check-in: ff256fb5 user: drh tags: trunk
13:06
Documentation updates. (CVS 1946) check-in: 799f5383 user: drh tags: trunk
2004-09-07
16:19
Wildcards with the same name map into the same variable number. New api sqlite3_bind_parameter_index() added to map wildcard names into wildcard index numbers. Support for "?nnn" wildcards. (CVS 1945) check-in: 435b3f30 user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to www/arch.tcl.

     1      1   #
     2      2   # Run this Tcl script to generate the sqlite.html file.
     3      3   #
     4         -set rcsid {$Id: arch.tcl,v 1.14 2004/07/17 21:56:10 drh Exp $}
            4  +set rcsid {$Id: arch.tcl,v 1.15 2004/09/08 13:06:21 drh Exp $}
     5      5   source common.tcl
     6      6   header {Architecture of SQLite}
     7      7   puts {
     8      8   <h2>The Architecture Of SQLite</h2>
     9      9   
    10     10   <h3>Introduction</h3>
    11     11   
................................................................................
    20     20   
    21     21   <p>
    22     22   A block diagram showing the main components of SQLite
    23     23   and how they interrelate is shown at the right.  The text that
    24     24   follows will provide a quick overview of each of these components.
    25     25   </p>
    26     26   
    27         -<h3>History</h3>
    28     27   
    29     28   <p>
    30         -There are two main C interfaces to the SQLite library:
    31         -<b>sqlite_exec()</b> and <b>sqlite_compile()</b>.  Prior to
    32         -version 2.8.0 (2003-Feb-16) only sqlite_exec() was supported.
    33         -For version 2.8.0, the sqlite_exec and sqlite_compile methods
    34         -existed as peers.  Beginning with version 2.8.13, the sqlite_compile
    35         -method is the primary interface, and sqlite_exec is implemented
    36         -using sqlite_compile.  Externally, this change is an enhancement
    37         -that maintains backwards compatibility.  But internally,
    38         -the plumbing is very different.  The diagram at the right shows
    39         -the structure of SQLite for version 2.8.13 and following.
    40         -</p>
    41         -
    42         -<p>
    43         -This document describes the structure for SQLite version 2.X.
    44         -SQLite version 3.0.0 introduces many new features and capabilities.
    45         -The basic architecture of the library remains the same.  However,
    46         -some of the details described here are different.  For example,
    47         -the code was in the file <b>os.c</b> has now been split out into
    48         -several file, on for each operating system.  And
    49         -the prefix on the names of API routines changed from <b>sqlite_</b>
    50         -to <b>sqlite3_</b>. 
           29  +This document describes SQLite version 3.0.  Version 2.8 and
           30  +earlier are similar but the details differ.
    51     31   </p>
    52     32   
    53     33   <h3>Interface</h3>
    54     34   
    55     35   <p>Much of the public interface to the SQLite library is implemented by
    56         -functions found in the <b>main.c</b> source file though some routines are
           36  +functions found in the <b>main.c</b>, <b>legacy.c</b>, and
           37  +<b>vdbeapi.c</b> source files
           38  +though some routines are
    57     39   scattered about in other files where they can have access to data 
    58     40   structures with file scope.  The
    59         -<b>sqlite_get_table()</b> routine is implemented in <b>table.c</b>.
    60         -<b>sqlite_step()</b> is found in <b>vdbe.c</b>.  
    61         -<b>sqlite_mprintf()</b> is found in <b>printf.c</b>.
           41  +<b>sqlite3_get_table()</b> routine is implemented in <b>table.c</b>.
           42  +<b>sqlite3_mprintf()</b> is found in <b>printf.c</b>.
           43  +<b>sqlite3_complete()</b> is in <b>tokenize.c</b>.
    62     44   The Tcl interface is implemented by <b>tclsqlite.c</b>.  More
    63     45   information on the C interface to SQLite is
    64         -<a href="c_interface.html">available separately</a>.<p>
           46  +<a href="capi3ref.html">available separately</a>.<p>
    65     47   
    66     48   <p>To avoid name collisions with other software, all external
    67         -symbols in the SQLite library begin with the prefix <b>sqlite</b>.
           49  +symbols in the SQLite library begin with the prefix <b>sqlite3</b>.
    68     50   Those symbols that are intended for external use (in other words,
    69     51   those symbols which form the API for SQLite) begin
    70         -with <b>sqlite_</b>.</p>
    71         -
    72         -<h3>SQL Command Processor</h3>
    73         -
    74         -<p>
           52  +with <b>sqlite3_</b>.</p>
    75     53   
    76     54   <h3>Tokenizer</h3>
    77     55   
    78     56   <p>When a string containing SQL statements is to be executed, the
    79     57   interface passes that string to the tokenizer.  The job of the tokenizer
    80     58   is to break the original string up into tokens and pass those tokens
    81         -one by one to the parser.  The tokenizer is hand-coded in C.
    82         -All of the code for the tokenizer
    83         -is contained in the <b>tokenize.c</b> source file.</p>
           59  +one by one to the parser.  The tokenizer is hand-coded in C in 
           60  +the file <b>tokenize.c</b>.
    84     61   
    85     62   <p>Note that in this design, the tokenizer calls the parser.  People
    86     63   who are familiar with YACC and BISON may be used to doing things the
    87     64   other way around -- having the parser call the tokenizer.  The author
    88     65   of SQLite 
    89     66   has done it both ways and finds things generally work out nicer for
    90     67   the tokenizer to call the parser.  YACC has it backwards.</p>
................................................................................
   109     86   </p>
   110     87   
   111     88   <h3>Code Generator</h3>
   112     89   
   113     90   <p>After the parser assembles tokens into complete SQL statements,
   114     91   it calls the code generator to produce virtual machine code that
   115     92   will do the work that the SQL statements request.  There are many
   116         -files in the code generator:  <b>build.c</b>, <b>copy.c</b>,
           93  +files in the code generator:
           94  +<b>attach.c</b>,
           95  +<b>auth.c</b>,
           96  +<b>build.c</b>,
   117     97   <b>delete.c</b>,
   118         -<b>expr.c</b>, <b>insert.c</b>, <b>pragma.c</b>,
   119         -<b>select.c</b>, <b>trigger.c</b>, <b>update.c</b>, <b>vacuum.c</b>
           98  +<b>expr.c</b>,
           99  +<b>insert.c</b>,
          100  +<b>pragma.c</b>,
          101  +<b>select.c</b>,
          102  +<b>trigger.c</b>,
          103  +<b>update.c</b>,
          104  +<b>vacuum.c</b>
   120    105   and <b>where.c</b>.
   121    106   In these files is where most of the serious magic happens.
   122    107   <b>expr.c</b> handles code generation for expressions.
   123    108   <b>where.c</b> handles code generation for WHERE clauses on
   124         -SELECT, UPDATE and DELETE statements.  The files <b>copy.c</b>,
          109  +SELECT, UPDATE and DELETE statements.  The files <b>attach.c</b>,
   125    110   <b>delete.c</b>, <b>insert.c</b>, <b>select.c</b>, <b>trigger.c</b>
   126    111   <b>update.c</b>, and <b>vacuum.c</b> handle the code generation
   127    112   for SQL statements with the same names.  (Each of these files calls routines
   128    113   in <b>expr.c</b> and <b>where.c</b> as necessary.)  All other
   129         -SQL statements are coded out of <b>build.c</b>.</p>
          114  +SQL statements are coded out of <b>build.c</b>.
          115  +The <b>auth.c</b> file implements the functionality of
          116  +<b>sqlite3_set_authorizer()</b>.</p>
   130    117   
   131    118   <h3>Virtual Machine</h3>
   132    119   
   133    120   <p>The program generated by the code generator is executed by
   134    121   the virtual machine.  Additional information about the virtual
   135    122   machine is <a href="opcode.html">available separately</a>.
   136    123   To summarize, the virtual machine implements an abstract computing
................................................................................
   142    129   <p>The virtual machine itself is entirely contained in a single
   143    130   source file <b>vdbe.c</b>.  The virtual machine also has
   144    131   its own header files: <b>vdbe.h</b> that defines an interface
   145    132   between the virtual machine and the rest of the SQLite library and
   146    133   <b>vdbeInt.h</b> which defines structure private the virtual machine.
   147    134   The <b>vdbeaux.c</b> file contains utilities used by the virtual
   148    135   machine and interface modules used by the rest of the library to
   149         -construct VM programs.</p>
          136  +construct VM programs.  The <b>vdbeapi.c</b> file contains external
          137  +interfaces to the virtual machine such as the 
          138  +<b>sqlite3_bind_...</b> family of functions.  Individual values
          139  +(strings, integer, floating point numbers, and BLOBs) are stored
          140  +in an internal object named "Mem" which is implemented by
          141  +<b>vdbemem.c</b>.</p>
          142  +
          143  +<p>
          144  +SQLite implements SQL functions using callbacks to C-language routines.
          145  +Even the built-in SQL functions are implemented this way.  Most of
          146  +the built-in SQL functions (ex: <b>coalesce()</b>, <b>count()</b>,
          147  +<b>substr()</b>, and so forth) can be found in <b>func.c</b>.
          148  +Date and time conversion functions are found in <b>date.c</b>.
          149  +</p>
   150    150   
   151    151   <h3>B-Tree</h3>
   152    152   
   153    153   <p>An SQLite database is maintained on disk using a B-tree implementation
   154    154   found in the <b>btree.c</b> source file.  A separate B-tree is used for
   155    155   each table and index in the database.  All B-trees are stored in the
   156         -same disk file.</p>
          156  +same disk file.  Details of the file format are recorded in a large
          157  +comment at the beginning of <b>btree.c</b>.</p>
   157    158   
   158    159   <p>The interface to the B-tree subsystem is defined by the header file
   159    160   <b>btree.h</b>.
   160    161   </p>
   161    162   
   162    163   <h3>Page Cache</h3>
   163    164   
   164         -<p>The B-tree module requests information from the disk in 1024 byte
   165         -chunks.  The page cache is reponsible for reading, writing, and
          165  +<p>The B-tree module requests information from the disk in fixed-size
          166  +chunks.  The default chunk size is 1024 bytes but can vary between 512
          167  +and 65536 bytes.
          168  +The page cache is reponsible for reading, writing, and
   166    169   caching these chunks.
   167    170   The page cache also provides the rollback and atomic commit abstraction
   168         -and takes care of reader/writer locking of the database file.  The
          171  +and takes care of locking of the database file.  The
   169    172   B-tree driver requests particular pages from the page cache and notifies
   170    173   the page cache when it wants to modify pages or commit or rollback
   171    174   changes and the page cache handles all the messy details of making sure
   172    175   the requests are handled quickly, safely, and efficiently.</p>
   173    176   
   174    177   <p>The code to implement the page cache is contained in the single C
   175    178   source file <b>pager.c</b>.  The interface to the page cache subsystem
................................................................................
   177    180   </p>
   178    181   
   179    182   <h3>OS Interface</h3>
   180    183   
   181    184   <p>
   182    185   In order to provide portability between POSIX and Win32 operating systems,
   183    186   SQLite uses an abstraction layer to interface with the operating system.
   184         -The <b>os.c</b> file contains about 20 routines used for opening and
   185         -closing files, deleting files, creating and deleting locks on files,
   186         -flushing the disk cache, and so forth.  Each of these functions contains
   187         -two implementations separated by #ifdefs: one for POSIX and the other
   188         -for Win32.  The interface to the OS abstraction layer is defined by
   189         -the <b>os.h</b> header file.
          187  +The interface to the OS abstraction layer is defined in
          188  +<b>os.h</b>.  Each supported operating system has its own implementation:
          189  +<b>os_unix.c</b> for Unix, <b>os_win.c</b> for windows, and so forth.
          190  +Each of these operating-specific implements typically has its own
          191  +header file: <b>os_unix.h</b>, <b>os_win.h</b>, etc.
          192  +</p>
          193  +
          194  +<h3>Utilities</h3>
          195  +
          196  +<p>
          197  +Memory allocation and caseless string comparison routines are located
          198  +in <b>util.c</b>.
          199  +Symbol tables used by the parser are maintained by hash tables found
          200  +in <b>hash.c</b>.  The <b>utf.c</b> source file contains Unicode
          201  +conversion subroutines.
          202  +SQLite has its own private implementation of <b>printf()</b> (with
          203  +some extensions) in <b>printf.c</b> and its own random number generator
          204  +in <b>random.c</b>.
          205  +</p>
          206  +
          207  +<h3>Test Code</h3>
          208  +
          209  +<p>
          210  +If you count regression test scripts,
          211  +more than half the total code base of SQLite is devoted to testing.
          212  +There are many <b>assert()</b> statements in the main code files.
          213  +In additional, the source files <b>test1.c</b> through <b>test5.c</b>
          214  +together with <b>md5.c</b> implement extensions used for testing
          215  +purposes only.  The <b>os_test.c</b> backend interface is used to
          216  +simulate power failures to verify the crash-recovery mechanism in
          217  +the pager.
   190    218   </p>
          219  +
   191    220   }
   192    221   footer $rcsid

Changes to www/arch2.gif.

cannot compute difference between binary files

Changes to www/lang.tcl.

     1      1   #
     2      2   # Run this Tcl script to generate the sqlite.html file.
     3      3   #
     4         -set rcsid {$Id: lang.tcl,v 1.71 2004/07/18 20:52:32 drh Exp $}
            4  +set rcsid {$Id: lang.tcl,v 1.72 2004/09/08 13:06:21 drh Exp $}
     5      5   source common.tcl
     6      6   header {Query Language Understood by SQLite}
     7      7   puts {
     8      8   <h2>SQL As Understood By SQLite</h2>
     9      9   
    10     10   <p>The SQLite library understands most of the standard SQL
    11     11   language.  But it does <a href="omitted.html">omit some features</a>
................................................................................
   179    179   }
   180    180   Syntax {sql-statement} {
   181    181   ROLLBACK [TRANSACTION [<name>]]
   182    182   }
   183    183   
   184    184   puts {
   185    185   <p>Beginning in version 2.0, SQLite supports transactions with
   186         -rollback and atomic commit.  See <a href="#attach">ATTACH</a> for
   187         -an exception when there are attached databases.</p>
          186  +rollback and atomic commit.</p>
   188    187   
   189    188   <p>The optional transaction name is ignored. SQLite currently 
   190    189   does not allow nested transactions.</p>
   191    190   
   192    191   <p>
   193    192   No changes can be made to the database except within a transaction.
   194    193   Any command that changes the database (basically, any SQL command
................................................................................
   257    256   [ USING DELIMITERS <delim> ]
   258    257   }
   259    258   
   260    259   puts {
   261    260   <p>The COPY command is available in SQLite version 2.8 and earlier.
   262    261   The COPY command has been removed from SQLite version 3.0 due to
   263    262   complications in trying to support it in a mixed UTF-8/16 environment.
          263  +In version 3.0, the <a href="sqlite.html">command-line shell</a>
          264  +contains a new command <b>.import</b> that can be used as a substitute
          265  +for COPY.
   264    266   </p>
   265    267   
   266    268   <p>The COPY command is an extension used to load large amounts of
   267    269   data into a table.  It is modeled after a similar command found
   268    270   in PostgreSQL.  In fact, the SQLite COPY command is specifically
   269    271   designed to be able to read the output of the PostgreSQL dump
   270    272   utility <b>pg_dump</b> so that data can be easily transferred from
................................................................................
   385    387   followed by the name of a new table and a parenthesized list of column
   386    388   definitions and constraints.  The table name can be either an identifier
   387    389   or a string.  Tables names that begin with "<b>sqlite_</b>" are reserved
   388    390   for use by the engine.</p>
   389    391   
   390    392   <p>Each column definition is the name of the column followed by the
   391    393   datatype for that column, then one or more optional column constraints.
   392         -SQLite is <a href="datatypes.html">typeless</a>.
   393    394   The datatype for the column does not restrict what data may be put
   394    395   in that column.
   395         -All information is stored as null-terminated strings.
          396  +See <a href="datatype3.html">Datatypes In SQLite Version 3</a> for
          397  +additional information.
   396    398   The UNIQUE constraint causes an index to be created on the specified
   397    399   columns.  This index must contain unique keys.
   398    400   The DEFAULT constraint
   399    401   specifies a default value to use when doing an INSERT.
   400    402   The COLLATE clause specifies what text collating function to use
   401    403   when comparing text entries for the column.  The built-in BINARY
   402    404   collating function is used by default.
................................................................................
   444    446   Support for CHECK constraints may be added in the future.  As of
   445    447   version 2.3.0, NOT NULL, PRIMARY KEY, and UNIQUE constraints all
   446    448   work.</p>
   447    449   
   448    450   <p>There are no arbitrary limits on the number
   449    451   of columns or on the number of constraints in a table.
   450    452   The total amount of data in a single row is limited to about
   451         -1 megabytes.  (This limit can be increased to 16MB by changing
   452         -a single #define in the source code and recompiling.)</p>
          453  +1 megabytes in version 2.8.  In version 3.0 there is no arbitrary
          454  +limit on the amount of data in a row.</p>
          455  +
   453    456   
   454    457   <p>The CREATE TABLE AS form defines the table to be
   455    458   the result set of a query.  The names of the table columns are
   456    459   the names of the columns in the result.</p>
   457    460   
   458    461   <p>The exact text
   459    462   of each CREATE TABLE statement is stored in the <b>sqlite_master</b>
................................................................................
   700    703   Section {DROP INDEX} dropindex
   701    704   
   702    705   Syntax {sql-command} {
   703    706   DROP INDEX [<database-name> .] <index-name>
   704    707   }
   705    708   
   706    709   puts {
   707         -<p>The DROP INDEX statement removes an index added with the <a href="#createindex">
          710  +<p>The DROP INDEX statement removes an index added
          711  +with the <a href="#createindex">
   708    712   CREATE INDEX</a> statement.  The index named is completely removed from
   709    713   the disk.  The only way to recover the index is to reenter the
   710    714   appropriate CREATE INDEX command.  Non-temporary indexes on tables in 
   711    715   an attached database cannot be dropped.</p>
   712    716   
   713    717   <p>The DROP INDEX statement does not reduce the size of the database 
   714    718   file.  Empty space in the database is retained for later INSERTs.  To 
................................................................................
   917    921   function can be used in any expression.  Simple functions return
   918    922   a result immediately based on their inputs.  Aggregate functions
   919    923   may only be used in a SELECT statement.  Aggregate functions compute
   920    924   their result across all rows of the result set.</p>
   921    925   
   922    926   <p>The functions shown below are available by default.  Additional
   923    927   functions may be written in C and added to the database engine using
   924         -the <a href="c_interface.html#cfunc">sqlite_create_function()</a>
          928  +the <a href="capi3ref.html#cfunc">sqlite3_create_function()</a>
   925    929   API.</p>
   926    930   
   927    931   <table border=0 cellpadding=10>
   928    932   <tr>
   929    933   <td valign="top" align="right" width=120>abs(<i>X</i>)</td>
   930    934   <td valign="top">Return the absolute value of argument <i>X</i>.</td>
   931    935   </tr>
................................................................................
   937    941   2 arguments.</td>
   938    942   </tr>
   939    943   
   940    944   <tr>
   941    945   <a name="globFunc"></a>
   942    946   <td valign="top" align="right">glob(<i>X</i>,<i>Y</i>)</td>
   943    947   <td valign="top">This function is used to implement the
   944         -"<b>Y GLOB X</b>" syntax of SQLite.  The
   945         -<a href="c_interface.html#cfunc">sqlite_create_function()</a> 
          948  +"<b>X GLOB Y</b>" syntax of SQLite.  The
          949  +<a href="capi3ref.html#sqlite3_create_function">sqlite3_create_function()</a> 
   946    950   interface can
   947    951   be used to override this function and thereby change the operation
   948    952   of the <a href="#glob">GLOB</a> operator.</td>
   949    953   </tr>
   950    954   
   951    955   <tr>
   952    956   <td valign="top" align="right">ifnull(<i>X</i>,<i>Y</i>)</td>
................................................................................
   969    973   characters is returned, not the number of bytes.</td>
   970    974   </tr>
   971    975   
   972    976   <tr>
   973    977   <a name="likeFunc"></a>
   974    978   <td valign="top" align="right">like(<i>X</i>,<i>Y</i>)</td>
   975    979   <td valign="top">This function is used to implement the
   976         -"<b>Y LIKE X</b>" syntax of SQL.  The
   977         -<a href="c_interface.html#cfunc">sqlite_create_function()</a> 
          980  +"<b>X LIKE Y</b>" syntax of SQL.  The
          981  +<a href="capi3ref.html#sqlite3_create_function">sqlite_create_function()</a> 
   978    982   interface can
   979    983   be used to override this function and thereby change the operation
   980    984   of the <a href="#like">LIKE</a> operator.</td>
   981    985   </tr>
   982    986   
   983    987   <tr>
   984    988   <td valign="top" align="right">lower(<i>X</i>)</td>
................................................................................
  1008   1012   
  1009   1013   <tr>
  1010   1014   <td valign="top" align="right">nullif(<i>X</i>,<i>Y</i>)</td>
  1011   1015   <td valign="top">Return the first argument if the arguments are different, 
  1012   1016   otherwise return NULL.</td>
  1013   1017   </tr>
  1014   1018   
         1019  +<tr>
         1020  +<td valign="top" align="right">quote(<i>X</i>)</td>
         1021  +<td valign="top">This routine returns a string which is the value of
         1022  +its argument suitable for inclusion into another SQL statement.
         1023  +Strings are surrounded by single-quotes with escapes on interior quotes
         1024  +as needed.  BLOBs are encoded as hexadecimal literals.
         1025  +The current implementation of VACUUM uses this function.  The function
         1026  +is also useful when writing triggers to implement undo/redo functionality.
         1027  +</td>
         1028  +</tr>
         1029  +
  1015   1030   <tr>
  1016   1031   <td valign="top" align="right">random(*)</td>
  1017   1032   <td valign="top">Return a random integer between -2147483648 and
  1018   1033   +2147483647.</td>
  1019   1034   </tr>
  1020   1035   
  1021   1036   <tr>
................................................................................
  1049   1064   right rather than the left.  If SQLite is configured to support UTF-8,
  1050   1065   then characters indices refer to actual UTF-8 characters, not bytes.</td>
  1051   1066   </tr>
  1052   1067   
  1053   1068   <tr>
  1054   1069   <td valign="top" align="right">typeof(<i>X</i>)</td>
  1055   1070   <td valign="top">Return the type of the expression <i>X</i>.  The only 
  1056         -return values are "numeric" and "text".  SQLite's type handling is 
  1057         -explained in <a href="datatypes.html">Datatypes in SQLite</a>.</td>
         1071  +return values are "null", "integer", "real", "text", and "blob".
         1072  +SQLite's type handling is 
         1073  +explained in <a href="datatype3.html">Datatypes in SQLite Version 3</a>.</td>
  1058   1074   </tr>
  1059   1075   
  1060   1076   <tr>
  1061   1077   <td valign="top" align="right">upper(<i>X</i>)</td>
  1062   1078   <td valign="top">Return a copy of input string <i>X</i> converted to all
  1063   1079   upper-case letters.  The implementation of this function uses the C library
  1064   1080   routine <b>toupper()</b> which means it may not work correctly on 
................................................................................
  1065   1081   UTF-8 strings.</td>
  1066   1082   </tr>
  1067   1083   </table>
  1068   1084   
  1069   1085   <p>
  1070   1086   The following aggregate functions are available by default.  Additional
  1071   1087   aggregate functions written in C may be added using the 
  1072         -<a href="c_interface.html#cfunc">sqlite_create_aggregate()</a> API.</p>
         1088  +<a href="capi3ref.html#sqlite3_create_function">sqlite3_create_function()</a>
         1089  +API.</p>
  1073   1090   
  1074   1091   <table border=0 cellpadding=10>
  1075   1092   <tr>
  1076   1093   <td valign="top" align="right" width=120>avg(<i>X</i>)</td>
  1077   1094   <td valign="top">Return the average value of all <i>X</i> within a group.</td>
  1078   1095   </tr>
  1079   1096   
................................................................................
  1266   1283       the main database.  The second row will be for the database used to 
  1267   1284       store temporary tables.</p></li>
  1268   1285   
  1269   1286   <a name="pragma_default_cache_size"></a>
  1270   1287   <li><p><b>PRAGMA default_cache_size;
  1271   1288          <br>PRAGMA default_cache_size = </b><i>Number-of-pages</i><b>;</b></p>
  1272   1289       <p>Query or change the maximum number of database disk pages that SQLite
  1273         -    will hold in memory at once.  Each page uses 1K on disk and about 1.5K in memory.
  1274         -    This pragma works like the <a href="#pragma_cache_size"><b>cache_size</b></a> 
         1290  +    will hold in memory at once.  Each page uses 1K on disk and about
         1291  +    1.5K in memory.
         1292  +    This pragma works like the
         1293  +    <a href="#pragma_cache_size"><b>cache_size</b></a> 
  1275   1294       pragma with the additional
  1276   1295       feature that it changes the cache size persistently.  With this pragma,
  1277   1296       you can set the cache size once and that setting is retained and reused
  1278   1297       everytime you reopen the database.</p></li>
  1279   1298   
  1280   1299   <a name="pragma_default_synchronous"></a>
  1281   1300   <li><p><b>PRAGMA default_synchronous;
................................................................................
  1304   1323       crashes or the computer loses power before that data has been written
  1305   1324       to the disk surface.  On the other hand, some
  1306   1325       operations are as much as 50 or more times faster with synchronous OFF.
  1307   1326       </p>
  1308   1327       <p>This pragma changes the synchronous mode persistently.  Once changed,
  1309   1328       the mode stays as set even if the database is closed and reopened.  The
  1310   1329       <a href="#pragma_synchronous"><b>synchronous</b></a> pragma does the same 
  1311         -    thing but only applies the setting to the current session.</p></li>
         1330  +    thing but only applies the setting to the current session.
         1331  +    
         1332  +    </p></li>
  1312   1333   
  1313   1334   <a name="pragma_default_temp_store"></a>
  1314   1335   <li><p><b>PRAGMA default_temp_store;
  1315   1336          <br>PRAGMA default_temp_store = DEFAULT; </b>(0)<b>
  1316   1337          <br>PRAGMA default_temp_store = MEMORY; </b>(2)<b>
  1317   1338          <br>PRAGMA default_temp_store = FILE;</b> (1)</p>
  1318   1339       <p>Query or change the setting of the "<b>temp_store</b>" flag stored in