Documentation Source Text

Check-in [daaf0b565e]
Login

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

Overview
Comment:Continuing work on the compile-time options document. This is an incremental check-in.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: daaf0b565eab5ba55a642910cb6ed7f0bf049572
User & Date: drh 2008-06-26 15:46:28.000
Context
2008-06-26
18:03
Bring the compile.html document up-to-date. (check-in: c6f9f40d64 user: drh tags: trunk)
15:46
Continuing work on the compile-time options document. This is an incremental check-in. (check-in: daaf0b565e user: drh tags: trunk)
13:11
Add the text "*** DRAFT ***" to every page if the file "DRAFT" appears in the build directory. Additional changes toward version 3.6.0. (check-in: 8bbca56f8e user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/35to36.in.
50
51
52
53
54
55
56



























































57
58
59
60
61
62
63

HEADING 1 {Incompatible Changes}

PARAGRAPH {
  Incompatible changes are covered first since they are the most
  important to maintainers and programmers.
}




























































HEADING 2 {Changes To The VFS Layer}

PARAGRAPH {
  SQLite [version 3.5.0] introduced a [34to35 | new OS interface layer] that
  provided an abstraction of the underlying operating system.
  This was an important innovation and has proven to be helpful







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122

HEADING 1 {Incompatible Changes}

PARAGRAPH {
  Incompatible changes are covered first since they are the most
  important to maintainers and programmers.
}
HEADING 2 {Overview Of Incompatible Changes}

PARAGRAPH {
  <ol>
  <li><p>Changes to the [sqlite3_vfs] object</p>

      <ol type="a">
      <li><p>The signature of the xAccess method has been modified to
      return an [error code] and to store its output into an integer pointed
      to by a parameter, rather than returning the output directly.
      This change allows the xAccess() method to report failures.
      In association with this signature change, a new 
      extended error code [SQLITE_IOERR_ACCESS] has been added.
      </p></li>

      <li><p>The xGetTempname method has been removed from [sqlite3_vfs].
      In its place, the xOpen method is enhanced to open a temporary file
      of its own invention when the filename parameter is NULL.</p></li>

      <li><p>Added the xGetLastError() method to [sqlite3_vfs] for returning
      filesyste-specific error messages and error codes back to SQLite.</p></li>
      </ol>
  </li>

  <li><p>The signature of the xCheckReservedLock method on [sqlite3_io_methods]
      has been modifed so that it returns an [error code] and stores its
      boolean result into an integer pointed to by a parameter.  In
      association with this change, a new extended error code
      [SQLITE_IOERR_CHECKRESERVEDLOCK] has been added.</p></li>

  <li><p>When SQLite is ported to new operation systems (operating systems 
      other unix, windows, and os/2 for which ports are provided together
      with the core)
      two new functions, [sqlite3_os_init()] and [sqlite3_os_end()], must
      be provided as part of the port.</p></li>

  <li><p>The way in which the IN and NOT IN operators handle NULL values
      in their right-hand expressions has been brought into compliance with
      the SQL standard and with other SQL database engines.</p></li>

  <li><p>Changes to compile-time options:</p>

      <ol type="a">
      <li><p>The SQLITE_MUTEX_APPDEF compile-time parameter is no longer
      recognized.  As a replacement, alternative 
      [sqlite3_mutex_enter | mutex implementations] may be created
      at runtime using [sqlite3_config()] with the [SQLITE_CONFIG_MUTEX]
      operator and the [sqlite3_mutex_methods] object.</p></li>

      <li><p>Compile-time options OS_UNIX, OS_WIN, OS_OS2, OS_OTHER, and
      TEMP_STORE have been renamed to include an "SQLITE_" prefix in order
      to help avoid namespace collisions with application software.  The
      new names of these options are respectively:
      SQLITE_OS_UNIX, SQLITE_OS_WIN, SQLITE_OS_OS2, SQLITE_OS_OTHER,
      and [SQLITE_TEMP_STORE].</p></li>
      </ol>
  </li>
  </ol>
}

HEADING 2 {Changes To The VFS Layer}

PARAGRAPH {
  SQLite [version 3.5.0] introduced a [34to35 | new OS interface layer] that
  provided an abstraction of the underlying operating system.
  This was an important innovation and has proven to be helpful
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
INDENTED {
  <b>Key Point:</b>  Changes to compile-time options have the potential
  to effect makefiles in projects that do customized builds of SQLite.
  Theses changes should have zero impact on application code and for
  most projects which use a standard, default build of SQLite.
}

HEADING 2 {Overview Of Incompatible Changes}

PARAGRAPH {
  The following outline gives more detail on the incompatible changes
  found in SQLite version 3.6.0, together with hyperlinks to other
  documents containing additional detail.
}
PARAGRAPH {
  <ol>
  <li><p>Changes to the [sqlite3_vfs] object</p>

      <ol type="a">
      <li><p>The signature of the xAccess method has been modified to
      return an [error code] and to store its output into an integer pointed
      to by a parameter, rather than returning the output directly.
      This change allows the xAccess() method to report failures.</p></li>

      <li><p>A new [error code], [SQLITE_IOERR_ACCESS], was added for cases
      where  the xAccess method of [sqlite3_vfs] fails due to an I/O
      error. </p></li>

      <li><p>The xGetTempname method has been removed from [sqlite3_vfs].
      In its place, the xOpen method is enhanced to open a temporary file
      of its own invention when the filename parameter is NULL.</p></li>

      <li><p>Added the xGetLastError() method to [sqlite3_vfs] for returning
      filesyste-specific error messages and error codes back to SQLite.</p></li>
      </ol>
  </li>

  <li><p>The signature of the xCheckReservedLock method on [sqlite3_io_methods]
      has been modifed so that it returns an [error code] and stores its
      boolean result into an integer pointed to by a parameter.</p></li>

  <li><p>When SQLite is ported to new operation systems (operating systems 
      other unix, windows, and os/2 for which ports are provided together
      with the core)
      two new functions, [sqlite3_os_init()] and [sqlite3_os_end()], must
      be provided as part of the port.</p></li>

  <li><p>The way in which the IN and NOT IN operators handle NULL values
      in their right-hand expressions has been brought into compliance with
      the SQL standard and with other SQL database engines.</p></li>

  <li><p>Changes to compile-time options:</p>

      <ol type="a">
      <li><p>The SQLITE_MUTEX_APPDEF compile-time parameter is no longer
      recognized.  As a replacement, alternative 
      [sqlite3_mutex_enter | mutex implementations] may be created
      at runtime using [sqlite3_config()] with the [SQLITE_CONFIG_MUTEX]
      operator and the [sqlite3_mutex_methods] object.</p></li>

      <li><p>Compile-time options OS_UNIX, OS_WIN, OS_OS2, OS_OTHER, and
      TEMP_STORE have been renamed to include an "SQLITE_" prefix in order
      to help avoid namespace collisions with application software.  The
      new names of these options are respectively:
      SQLITE_OS_UNIX, SQLITE_OS_WIN, SQLITE_OS_OS2, SQLITE_OS_OTHER,
      and SQLITE_TEMP_STORE.</p></li>
      </ol>
  </li>
  </ol>
}

HEADING 1 {Fully Backwards-Compatible Enhancements}

PARAGRAPH {
  In addition to the incompatible changes listed above, SQLite
  version 3.6.0 adds the following backwards compatible changes and
  enhancements:







<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<







209
210
211
212
213
214
215































































216
217
218
219
220
221
222
INDENTED {
  <b>Key Point:</b>  Changes to compile-time options have the potential
  to effect makefiles in projects that do customized builds of SQLite.
  Theses changes should have zero impact on application code and for
  most projects which use a standard, default build of SQLite.
}

































































HEADING 1 {Fully Backwards-Compatible Enhancements}

PARAGRAPH {
  In addition to the incompatible changes listed above, SQLite
  version 3.6.0 adds the following backwards compatible changes and
  enhancements:
Changes to pages/compile.in.
24
25
26
27
28
29
30

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


















47
48
49
50
51
52
53
<tcl>
proc COMPILE_OPTION {name text} {
  if {[regexp {SQLITE_([A-Z0-9_]+)} $name all label]} {
    hd_fragment [string tolower $label]
    hd_keywords $all
  }
  hd_puts <p><b>$name</b></p>

  hd_resolve <blockquote>$text</blockquote>
}

COMPILE_OPTION {SQLITE_DEFAULT_AUTOVACUUM=<i>&lt;1 or 0&gt;</i>} {
  This macro determines if SQLite creates databases with the 
  [auto_vacuum] flag set by default. The default value is 0 
  (do not create auto-vacuum databases). In any case the
  compile-time default may be overridden by the 
  [PRAGMA auto_vacuum] command.
}

COMPILE_OPTION {SQLITE_DEFAULT_CACHE_SIZE=<i>&lt;pages&gt;</i>} {
  This macro sets the default size of the page-cache for each attached
  database, in pages. This can be overridden by the 
  [PRAGMA cache_size] comamnd. The default value is 2000.
}



















COMPILE_OPTION {SQLITE_DEFAULT_PAGE_SIZE=<i>&lt;bytes&gt;</i>} {
  This macro is used to set the default page-size used when a
  database is created. The value assigned must be a power of 2. The
  default value is 1024. The compile-time default may be overridden at 
  runtime by the [PRAGMA page_size] command.
}







>
|















>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<tcl>
proc COMPILE_OPTION {name text} {
  if {[regexp {SQLITE_([A-Z0-9_]+)} $name all label]} {
    hd_fragment [string tolower $label]
    hd_keywords $all
  }
  hd_puts <p><b>$name</b></p>
  regsub -all "\n\\s*\n" $text "</p>\n\n<p>" text
  hd_resolve <blockquote><p>$text</p></blockquote>
}

COMPILE_OPTION {SQLITE_DEFAULT_AUTOVACUUM=<i>&lt;1 or 0&gt;</i>} {
  This macro determines if SQLite creates databases with the 
  [auto_vacuum] flag set by default. The default value is 0 
  (do not create auto-vacuum databases). In any case the
  compile-time default may be overridden by the 
  [PRAGMA auto_vacuum] command.
}

COMPILE_OPTION {SQLITE_DEFAULT_CACHE_SIZE=<i>&lt;pages&gt;</i>} {
  This macro sets the default size of the page-cache for each attached
  database, in pages. This can be overridden by the 
  [PRAGMA cache_size] comamnd. The default value is 2000.
}

COMPILE_OPTION {SQLITE_DEFAULT_FILE_FORMAT=<i>&lt;1 or 4&gt;</i>} {
  The default schema-level file format used by SQLite when creating
  new database files is set by this macro.  The file formats are all
  very similar.  The difference between formats 1 and 4 is that format
  4 understands descending indices and has a tighter encoding for
  boolean values.

  SQLite (as of [version 3.6.0]) can read and write any file format
  between 1 and 4.  But older versions of SQLite might not be able to
  read formats greater than 1.  So that older versions of SQLite will
  be able to read and write database files created by newer versions
  of SQLite, the default file format is set to 1 for maximum
  compatability.

  The file format for a new database can be set at runtime using
  the [PRAGMA legacy_file_format] command.
}

COMPILE_OPTION {SQLITE_DEFAULT_PAGE_SIZE=<i>&lt;bytes&gt;</i>} {
  This macro is used to set the default page-size used when a
  database is created. The value assigned must be a power of 2. The
  default value is 1024. The compile-time default may be overridden at 
  runtime by the [PRAGMA page_size] command.
}
94
95
96
97
98
99
100
101
102
103
104
105
106
107



















108
109
110
111
112
113
114
COMPILE_OPTION {SQLITE_THREADSAFE=<i>&lt;0 or 1&gt;</i>} {
  This option controls whether or not code is included in SQLite to
  enable it to operate safely in a multithreaded environment.  The
  default is SQLITE_THREADSAFE=1 which is safe for use in a multithreaded
  environment.  When compiled with SQLITE_THREADSAFE=0 all mutexing code
  is omitted and it is unsafe to use SQLite in a multithreaded program.

  <p>The value of SQLITE_THREADSAFE can be determined at run-time
  using the [sqlite3_threadsafe()] interface.</p>

  <p>When SQLite has been compiled with SQLITE_THREADSAFE=1 then mutexing
  can be disabled at run-time using the [sqlite3_config()] interface together
  with the [SQLITE_CONFIG_SINGLETHREAD], [SQLITE_CONFIG_MULTITHREAD], and
  [SQLITE_CONFIG_SERIALIZED] verbs.</p>



















}
</tcl>

<a name="enablefeatures"></a>
<h2>1.4 Options To Enable Features Normally Turned Off</h2>

<a name="omitfeatures"></a>







|
|

|


|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
COMPILE_OPTION {SQLITE_THREADSAFE=<i>&lt;0 or 1&gt;</i>} {
  This option controls whether or not code is included in SQLite to
  enable it to operate safely in a multithreaded environment.  The
  default is SQLITE_THREADSAFE=1 which is safe for use in a multithreaded
  environment.  When compiled with SQLITE_THREADSAFE=0 all mutexing code
  is omitted and it is unsafe to use SQLite in a multithreaded program.

  The value of SQLITE_THREADSAFE can be determined at run-time
  using the [sqlite3_threadsafe()] interface.

  When SQLite has been compiled with SQLITE_THREADSAFE=1 then mutexing
  can be disabled at run-time using the [sqlite3_config()] interface together
  with the [SQLITE_CONFIG_SINGLETHREAD], [SQLITE_CONFIG_MULTITHREAD], and
  [SQLITE_CONFIG_SERIALIZED] verbs.
}

COMPILE_OPTION {SQLITE_TEMP_STORE=<i>&lt;0 through 3&gt;</i>} {
  This option controls whether temporary files are stored on disk or
  in memory.  The meanings for various settings of this compile-time
  option are as follows:

  <table cellpadding="2" border="1">
  <tr><th>SQLITE_TEMP_STORE</th><th>Meaning</th></tr>
  <tr><td align="center">0</td><td>Always use temporary files</td></tr>
  <tr><td align="center">1</td><td>Use files by default but allow the
  [PRAGMA temp_store] command to override</td></tr>
  <tr><td align="center">2</td><td>Use memory by default but allow the
  [PRAGMA temp_store] command to override</td></tr>
  <tr><td align="center">3</td><td>Always use memory</td></tr>
  </table>

  The default setting is 1.  
  Additional information can be found in [tempstore | tempfiles.html].
}
</tcl>

<a name="enablefeatures"></a>
<h2>1.4 Options To Enable Features Normally Turned Off</h2>

<a name="omitfeatures"></a>
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298

COMPILE_OPTION {SQLITE_OMIT_TRIGGER} {
  Defining this option omits support for VIEW objects. Neither the 
  [CREATE TRIGGER] or [DROP TRIGGER]
  commands are available in this case, and attempting to execute
  either will result in a parse error.

  <p>
  WARNING: If this macro is defined, it will not be possible to open a database
  for which the schema contains TRIGGER objects. 
  </p>
}

COMPILE_OPTION {SQLITE_OMIT_UTF16} {
  This macro is used to omit support for UTF16 text encoding. When this is
  defined all API functions that return or accept UTF16 encoded text are
  unavailable. These functions can be identified by the fact that they end
  with '16', for example [sqlite3_prepare16()], [sqlite3_column_text16()] and







<


<







319
320
321
322
323
324
325

326
327

328
329
330
331
332
333
334

COMPILE_OPTION {SQLITE_OMIT_TRIGGER} {
  Defining this option omits support for VIEW objects. Neither the 
  [CREATE TRIGGER] or [DROP TRIGGER]
  commands are available in this case, and attempting to execute
  either will result in a parse error.


  WARNING: If this macro is defined, it will not be possible to open a database
  for which the schema contains TRIGGER objects. 

}

COMPILE_OPTION {SQLITE_OMIT_UTF16} {
  This macro is used to omit support for UTF16 text encoding. When this is
  defined all API functions that return or accept UTF16 encoded text are
  unavailable. These functions can be identified by the fact that they end
  with '16', for example [sqlite3_prepare16()], [sqlite3_column_text16()] and
308
309
310
311
312
313
314
315
316
317
318
319
320

COMPILE_OPTION {SQLITE_OMIT_VIEW} {
  Defining this option omits support for VIEW objects. Neither the 
  [CREATE VIEW] nor the [DROP VIEW]
  commands are available in this case, and
  attempting to execute either will result in a parse error.

  <p>
  WARNING: If this macro is defined, it will not be possible to open a database
  for which the schema contains VIEW objects. 
  </p>
}
</tcl>







<


<


344
345
346
347
348
349
350

351
352

353
354

COMPILE_OPTION {SQLITE_OMIT_VIEW} {
  Defining this option omits support for VIEW objects. Neither the 
  [CREATE VIEW] nor the [DROP VIEW]
  commands are available in this case, and
  attempting to execute either will result in a parse error.


  WARNING: If this macro is defined, it will not be possible to open a database
  for which the schema contains VIEW objects. 

}
</tcl>
Changes to pages/pragma.in.
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
  }
  hd_puts "<h1>$name</h1>\n"
}
proc Subsection {args} {
  set f [lindex $args 0]
  hd_fragment pragma_$f
  foreach x $args {
    hd_keywords $x "PRAGMA $x"
  }
}
</tcl>

<p>The [PRAGMA] statement is a special SQL statement used to 
modify the operation of the SQLite library or to query the library for 
internal (non-table) data. The [PRAGMA] statement is issued using the same







|







11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
  }
  hd_puts "<h1>$name</h1>\n"
}
proc Subsection {args} {
  set f [lindex $args 0]
  hd_fragment pragma_$f
  foreach x $args {
    hd_keywords $x "PRAGMA $x" "$x pragma"
  }
}
</tcl>

<p>The [PRAGMA] statement is a special SQL statement used to 
modify the operation of the SQLite library or to query the library for 
internal (non-table) data. The [PRAGMA] statement is issued using the same
358
359
360
361
362
363
364



365
366
367
368
369
370
371
    <p>When the pragma is issued with no argument, it returns the
    setting of the flag.  This pragma does <u>not</u> tell which
    file format the current database is using.  It tells what format
    will be used by any newly created databases.</p>

    <p>This flag only affects newly created databases.  It has no
    effect on databases that already exist.</p>



</li>

<tcl>Subsection locking_mode</tcl>
<li><p><b>PRAGMA locking_mode;
       <br>PRAGMA locking_mode = <i>NORMAL | EXCLUSIVE</i></b></p>
    <p>This pragma sets or queries the database connection locking-mode. 
    The locking-mode is either NORMAL or EXCLUSIVE.







>
>
>







358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
    <p>When the pragma is issued with no argument, it returns the
    setting of the flag.  This pragma does <u>not</u> tell which
    file format the current database is using.  It tells what format
    will be used by any newly created databases.</p>

    <p>This flag only affects newly created databases.  It has no
    effect on databases that already exist.</p>

    <p>The default file format is set by the
    [SQLITE_DEFAULT_FILE_FORMAT] compile-time option.</p>
</li>

<tcl>Subsection locking_mode</tcl>
<li><p><b>PRAGMA locking_mode;
       <br>PRAGMA locking_mode = <i>NORMAL | EXCLUSIVE</i></b></p>
    <p>This pragma sets or queries the database connection locking-mode. 
    The locking-mode is either NORMAL or EXCLUSIVE.
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548

549
550
551
552
553
554
555
556
557
558
559
560
561
562
<tcl>Subsection temp_store</tcl>
<li><p><b>PRAGMA temp_store;
       <br>PRAGMA temp_store = DEFAULT;</b> (0)<b>
       <br>PRAGMA temp_store = FILE;</b> (1)<b>
       <br>PRAGMA temp_store = MEMORY;</b> (2)</p>
    <p>Query or change the setting of the "<b>temp_store</b>" parameter.
    When temp_store is DEFAULT (0), the compile-time C preprocessor macro
    TEMP_STORE is used to determine where temporary tables and indices
    are stored.  When
    temp_store is MEMORY (2) temporary tables and indices are kept in memory.
    When temp_store is FILE (1) temporary tables and indices are stored
    in a file.  The <a href="#pragma_temp_store_directory">
    temp_store_directory</a> pragma can be used to specify the directory
    containing this file.
    <b>FILE</b> is specified. When the temp_store setting is changed,
    all existing temporary tables, indices, triggers, and views are
    immediately deleted.</p>

    <p>It is possible for the library compile-time C preprocessor symbol

    TEMP_STORE to override this pragma setting.  The following table summarizes
    the interaction of the TEMP_STORE preprocessor macro and the
    temp_store pragma:</p>

    <blockquote>
    <table cellpadding="2" border="1">
    <tr><th valign="bottom">TEMP_STORE</th>
        <th valign="bottom">PRAGMA<br>temp_store</th>
        <th>Storage used for<br>TEMP tables and indices</th></tr>
    <tr><td align="center">0</td>
        <td align="center"><em>any</em></td>
        <td align="center">file</td></tr>
    <tr><td align="center">1</td>
        <td align="center">0</td>







|











>
|
|




|







533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
<tcl>Subsection temp_store</tcl>
<li><p><b>PRAGMA temp_store;
       <br>PRAGMA temp_store = DEFAULT;</b> (0)<b>
       <br>PRAGMA temp_store = FILE;</b> (1)<b>
       <br>PRAGMA temp_store = MEMORY;</b> (2)</p>
    <p>Query or change the setting of the "<b>temp_store</b>" parameter.
    When temp_store is DEFAULT (0), the compile-time C preprocessor macro
    [SQLITE_TEMP_STORE] is used to determine where temporary tables and indices
    are stored.  When
    temp_store is MEMORY (2) temporary tables and indices are kept in memory.
    When temp_store is FILE (1) temporary tables and indices are stored
    in a file.  The <a href="#pragma_temp_store_directory">
    temp_store_directory</a> pragma can be used to specify the directory
    containing this file.
    <b>FILE</b> is specified. When the temp_store setting is changed,
    all existing temporary tables, indices, triggers, and views are
    immediately deleted.</p>

    <p>It is possible for the library compile-time C preprocessor symbol
    [SQLITE_TEMP_STORE] to override this pragma setting.
    The following table summarizes
    the interaction of the [SQLITE_TEMP_STORE] preprocessor macro and the
    temp_store pragma:</p>

    <blockquote>
    <table cellpadding="2" border="1">
    <tr><th valign="bottom">[SQLITE_TEMP_STORE]</th>
        <th valign="bottom">PRAGMA<br>temp_store</th>
        <th>Storage used for<br>TEMP tables and indices</th></tr>
    <tr><td align="center">0</td>
        <td align="center"><em>any</em></td>
        <td align="center">file</td></tr>
    <tr><td align="center">1</td>
        <td align="center">0</td>
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
<li><p><b>PRAGMA index_list(</b><i>table-name</i><b>);</b></p>
    <p>For each index on the named table, invoke the callback function
    once with information about that index.  Arguments include the
    index name and a flag to indicate whether or not the index must be
    unique.</p></li>

<tcl>Subsection page_count</tcl>
<li><p><b>PRAGMA &#91;database&#91;.page_count;</b></p>
    <p>Return the total number of pages in the database file.</p></li>

<tcl>Subsection table_info</tcl>
<li><p><b>PRAGMA table_info(</b><i>table-name</i><b>);</b></p>
    <p>For each column in the named table, invoke the callback function
    once with information about that column, including the column name,
    data type, whether or not the column can be NULL, and the default







|







657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
<li><p><b>PRAGMA index_list(</b><i>table-name</i><b>);</b></p>
    <p>For each index on the named table, invoke the callback function
    once with information about that index.  Arguments include the
    index name and a flag to indicate whether or not the index must be
    unique.</p></li>

<tcl>Subsection page_count</tcl>
<li><p><b>PRAGMA &#91;database&#93;.page_count;</b></p>
    <p>Return the total number of pages in the database file.</p></li>

<tcl>Subsection table_info</tcl>
<li><p><b>PRAGMA table_info(</b><i>table-name</i><b>);</b></p>
    <p>For each column in the named table, invoke the callback function
    once with information about that column, including the column name,
    data type, whether or not the column can be NULL, and the default
Changes to pages/tempfiles.in.
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
journal to restore the database to its state prior to the start
of the incomplete transaction.  This is how SQLite implements
atomic commit.
</p>

<p>
If an application puts SQLite in 
<a href="pragma.html#pragma_locking_mode">exclusive locking mode</a> using
the pragma:
</p>

<blockquote><pre>
PRAGMA locking_mode=EXCLUSIVE;
</pre></blockquote>

<p>
SQLite creates a new rollback journal at the start of the first
transaction within an exclusive locking mode session.  But at the
conclusion of the transaction, it does not delete the rollback
journal.  The rollback journal might be truncated, or its header
might be zeroed (depending on what version of SQLite you are using)
but the rollback journal is not deleted.  The rollback journal is
not deleted until exclusive access mode is exited.</p>

<p>
Rollback journal creation and deletion is also changed by the
<a href="pragma.html#pragma_journal_mode">journal_mode pragma</a>.
The default journaling mode is DELETE, which is the default behavior
of deleting the rollback journal file at the end of each transaction,
as described above.  The PERSIST journal mode foregoes the deletion of
the journal file and instead overwrites the rollback journal header
with zeros, which prevents other processes from rolling back the
journal and thus has the same effect as deleting the journal file, though
without the expense of actually removing the file from disk.  In other







|


















|







94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
journal to restore the database to its state prior to the start
of the incomplete transaction.  This is how SQLite implements
atomic commit.
</p>

<p>
If an application puts SQLite in 
[PRAGMA locking_mode | exclusive locking mode] using
the pragma:
</p>

<blockquote><pre>
PRAGMA locking_mode=EXCLUSIVE;
</pre></blockquote>

<p>
SQLite creates a new rollback journal at the start of the first
transaction within an exclusive locking mode session.  But at the
conclusion of the transaction, it does not delete the rollback
journal.  The rollback journal might be truncated, or its header
might be zeroed (depending on what version of SQLite you are using)
but the rollback journal is not deleted.  The rollback journal is
not deleted until exclusive access mode is exited.</p>

<p>
Rollback journal creation and deletion is also changed by the
[journal_mode pragma].
The default journaling mode is DELETE, which is the default behavior
of deleting the rollback journal file at the end of each transaction,
as described above.  The PERSIST journal mode foregoes the deletion of
the journal file and instead overwrites the rollback journal header
with zeros, which prevents other processes from rolling back the
journal and thus has the same effect as deleting the journal file, though
without the expense of actually removing the file from disk.  In other
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
constraint or a RAISE exception within a trigger and thus need to
undo partial results.
If the UPDATE or INSERT is not contained within BEGIN...COMMIT and if
there are no other active statements on the same database connection then
no statement journal is created since the ordinary
rollback journal can be used instead.
The statement journal is also omitted if an alternative
<a href="lang_conflict.html">conflict resolution algorithm</a> is
used.  For example:
</p>

<blockquote><pre>
UPDATE OR FAIL ...
UPDATE OR IGNORE ...
UPDATE OR REPLACE ...







|







191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
constraint or a RAISE exception within a trigger and thus need to
undo partial results.
If the UPDATE or INSERT is not contained within BEGIN...COMMIT and if
there are no other active statements on the same database connection then
no statement journal is created since the ordinary
rollback journal can be used instead.
The statement journal is also omitted if an alternative
[ON CONFLICT | conflict resolution algorithm] is
used.  For example:
</p>

<blockquote><pre>
UPDATE OR FAIL ...
UPDATE OR IGNORE ...
UPDATE OR REPLACE ...
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
<p>
The TEMP database file is very similar to auxiliary database
files added using the [ATTACH] statement, though with a few
special properties.
The TEMP database is always automatically deleted when the
[database connection] is closed.
The TEMP database always uses the
<a href="pragma.html#pragma_synchronous">synchronous=OFF</a> and
<a href="pragma.html#pragma_journal_mode">journal_mode=PERSIST</a>
[PRAGMA] settings.
And, the TEMP database cannot be used with [DETACH] nor can
another process [ATTACH] the TEMP database.
</p>

<p>
The temporary files associated with the TEMP database and its
rollback journal are only created if the application makes use







<
|
|







236
237
238
239
240
241
242

243
244
245
246
247
248
249
250
251
<p>
The TEMP database file is very similar to auxiliary database
files added using the [ATTACH] statement, though with a few
special properties.
The TEMP database is always automatically deleted when the
[database connection] is closed.
The TEMP database always uses the

[synchronous=OFF] and [journal_mode=PERSIST]
PRAGMA settings.
And, the TEMP database cannot be used with [DETACH] nor can
another process [ATTACH] the TEMP database.
</p>

<p>
The temporary files associated with the TEMP database and its
rollback journal are only created if the application makes use
463
464
465
466
467
468
469

470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575

<p>
The temporary file created by the [VACUUM] command exists only
for the duration of the command itself.  The size of the temporary
file will be no larger than the original database.
</p>


<h2>3.0 The TEMP_STORE Compile-Time Parameter and Pragma</h2>

<p>
The rollback journal, master journal,
and statement journal files are always written
to disk.
But the other kinds of temporary files might be stored in memory
only and never written to disk.
Whether or not temporary files other than the rollback,
master, and statement journals are written to disk or stored only in memory
depends on the TEMP_STORE compile-time parameter, the
<a href="pragma.html#pragma_temp_store">temp_store</a> [PRAGMA],
and on the size of the temporary file.
</p>

<p>
The TEMP_STORE compile-time parameter is a #define whose value is
an integer between 0 and 3, inclusive.  The meaning of the
TEMP_STORE compile-time parameter is as follows:
</p>

<ol type="1">
<li value="0">
Temporary files are always stored on disk regardless of the setting
of the <a href="pragma.html#pragma_temp_store">temp_store pragma</a>.
</li>
<li value="1">
Temporary files are stored on disk by default but this can be
overridden by the <a href="pragma.html#pragma_temp_store">temp_store pragma</a>.
</li>
<li value="2">
Temporary files are stored in memory by default but this can be
overridden by the <a href="pragma.html#pragma_temp_store">temp_store pragma</a>.
</li>
<li value="3">
Temporary files are always stored in memory regardless of the setting
of the <a href="pragma.html#pragma_temp_store">temp_store pragma</a>.
</li>
</ol>

<p>
The default value of the TEMP_STORE compile-time parameter is 1,
which means to store temporary files on disk but provide the option
of overriding the behavior using the
<a href="pragma.html#pragma_temp_store">temp_store pragma</a>.
</p>

<p>
The <a href="pragma.html#pragma_temp_store">temp_store pragma</a> has
an integer value which also influences the decision of where to store
temporary files.  The values of the the temp_store pragma have the
following meanings:
</p>

<ol type="1">
<li value="0">
Use either disk or memory storage for temporary files as determined
by the TEMP_STORE compile-time parameter.
</li>
<li value="1">
If the TEMP_STORE compile-time parameter specifies memory storage for
temporary files, then override that decision and use disk storage instead.
Otherwise follow the recommendation of the TEMP_STORE compile-time
parameter.
</li>
<li value="2">
If the TEMP_STORE compile-time parameter specifies disk storage for
temporary files, then override that decision and use memory storage instead.
Otherwise follow the recommendation of the TEMP_STORE compile-time
parameter.
</li>
</ol>

<p>
The default setting for the 
<a href="pragma.html#pragma_temp_store">temp_store pragma</a> is 0,
which means to following the recommendation of TEMP_STORE compile-time
parameter.
</p>

<p>
To reiterate, the TEMP_STORE compile-time parameter an the 
<a href="pragma.html#pragma_temp_store">temp_store pragma</a> only
influence the temporary files other than the rollback journal
and the master journal.  The rollback journal and the master
journal are always written to disk regardless of the settings of
the TEMP_STORE compile-time parameter and the
<a href="pragma.html#pragma_temp_store">temp_store pragma</a>.
</p>

<h2>4.0 Other Temporary File Optimizations</h2>

<p>
SQLite uses a page cache of recently read and written database
pages.  This page cache is used not just for the main database
file but also for transient indices and tables stored in temporary
files.  If SQLite needs to use a temporary index or table and
the TEMP_STORE compile-time parameter and the
<a href="pragma.html#pragma_temp_store">temp_store pragma</a> are
set to store temporary tables and index on disk, the information
is still initially stored in memory in the page cache.  The 
temporary file is not opened and the information is not truly
written to disk until the page cache is full.
</p>

<p>







>
|









|
|




|

|





|



|



|



|




|

|
<



|








|


|

|



|

|





|
<
|




|
|



|
|









|
|







462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513

514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543

544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573

<p>
The temporary file created by the [VACUUM] command exists only
for the duration of the command itself.  The size of the temporary
file will be no larger than the original database.
</p>

<tcl>hd_fragment tempstore; hd_keywords tempstore</tcl>
<h2>3.0 The SQLITE_TEMP_STORE Compile-Time Parameter and Pragma</h2>

<p>
The rollback journal, master journal,
and statement journal files are always written
to disk.
But the other kinds of temporary files might be stored in memory
only and never written to disk.
Whether or not temporary files other than the rollback,
master, and statement journals are written to disk or stored only in memory
depends on the [SQLITE_TEMP_STORE] compile-time parameter, the
[temp_store pragma],
and on the size of the temporary file.
</p>

<p>
The [SQLITE_TEMP_STORE] compile-time parameter is a #define whose value is
an integer between 0 and 3, inclusive.  The meaning of the
[SQLITE_TEMP_STORE] compile-time parameter is as follows:
</p>

<ol type="1">
<li value="0">
Temporary files are always stored on disk regardless of the setting
of the [temp_store pragma].
</li>
<li value="1">
Temporary files are stored on disk by default but this can be
overridden by the [temp_store pragma].
</li>
<li value="2">
Temporary files are stored in memory by default but this can be
overridden by the [temp_store pragma].
</li>
<li value="3">
Temporary files are always stored in memory regardless of the setting
of the [temp_store pragma].
</li>
</ol>

<p>
The default value of the [SQLITE_TEMP_STORE] compile-time parameter is 1,
which means to store temporary files on disk but provide the option
of overriding the behavior using the [temp_store pragma].

</p>

<p>
The [temp_store pragma] has
an integer value which also influences the decision of where to store
temporary files.  The values of the the temp_store pragma have the
following meanings:
</p>

<ol type="1">
<li value="0">
Use either disk or memory storage for temporary files as determined
by the [SQLITE_TEMP_STORE] compile-time parameter.
</li>
<li value="1">
If the [SQLITE_TEMP_STORE] compile-time parameter specifies memory storage for
temporary files, then override that decision and use disk storage instead.
Otherwise follow the recommendation of the [SQLITE_TEMP_STORE] compile-time
parameter.
</li>
<li value="2">
If the [SQLITE_TEMP_STORE] compile-time parameter specifies disk storage for
temporary files, then override that decision and use memory storage instead.
Otherwise follow the recommendation of the [SQLITE_TEMP_STORE] compile-time
parameter.
</li>
</ol>

<p>
The default setting for the [temp_store pragma] is 0,

which means to following the recommendation of [SQLITE_TEMP_STORE] compile-time
parameter.
</p>

<p>
To reiterate, the [SQLITE_TEMP_STORE] compile-time parameter an the 
[temp_store pragma] only
influence the temporary files other than the rollback journal
and the master journal.  The rollback journal and the master
journal are always written to disk regardless of the settings of
the [SQLITE_TEMP_STORE] compile-time parameter and the
[temp_store pragma].
</p>

<h2>4.0 Other Temporary File Optimizations</h2>

<p>
SQLite uses a page cache of recently read and written database
pages.  This page cache is used not just for the main database
file but also for transient indices and tables stored in temporary
files.  If SQLite needs to use a temporary index or table and
the [SQLITE_TEMP_STORE] compile-time parameter and the
[temp_store pragma] are
set to store temporary tables and index on disk, the information
is still initially stored in memory in the page cache.  The 
temporary file is not opened and the information is not truly
written to disk until the page cache is full.
</p>

<p>