Documentation Source Text

Check-in [1894a02a1f]
Login

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

Overview
Comment:Fix documentation typos.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 1894a02a1f4ee3113f864d4e56c6a02cdd4b346dd4c7f264c87f9ffd43eeb2ce
User & Date: drh 2020-01-22 17:49:40
Context
2020-01-22
17:53
Add news for the 3.31.0 release. check-in: 0e92e9f7c1 user: drh tags: trunk
17:49
Fix documentation typos. check-in: 1894a02a1f user: drh tags: trunk
17:13
Updates to the generated column documentation. check-in: 2d23316bb5 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/changes.in.

344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
<li>The --deserialize option associated with opening a new database cause the
    database file to be read into memory and accessed using the
    [sqlite3_deserialize()] API. This simplifies running tests on a database
    without modifying the file on disk.
</ol>
<li>Enhancements to the [geopoly] extension:
<ol type="a">
<li>Aways stores polygons
    using the binary format, which is faster and uses less space.
<li>Added the [geopoly_regular()] function.
<li>Added the [geopoly_ccw()] function.
</ol>
<li>Enhancements to the [session] extension:
<ol type="a">
<li>Added the [SQLITE_CHANGESETAPPLY_INVERT] flag







|







344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
<li>The --deserialize option associated with opening a new database cause the
    database file to be read into memory and accessed using the
    [sqlite3_deserialize()] API. This simplifies running tests on a database
    without modifying the file on disk.
</ol>
<li>Enhancements to the [geopoly] extension:
<ol type="a">
<li>Always stores polygons
    using the binary format, which is faster and uses less space.
<li>Added the [geopoly_regular()] function.
<li>Added the [geopoly_ccw()] function.
</ol>
<li>Enhancements to the [session] extension:
<ol type="a">
<li>Added the [SQLITE_CHANGESETAPPLY_INVERT] flag

Changes to pages/compile.in.

111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
of the [bytecode engine].  By omitting this interface, a single conditional
is removed from the inner loop of the [bytecode engine], helping SQL statements
to run slightly faster.

<li><p><b>[SQLITE_OMIT_SHARED_CACHE]</b>.
Omitting the possibility of using [shared cache] allows many conditionals
in performance-critical sections of the code to be eliminated.  This can
give a noticable improvement in performance.

<li><p><b>[SQLITE_USE_ALLOCA]</b>.
Make use of alloca() for dynamically allocating temporary stack space for 
use within a single function, on systems that support alloca().  Without
this option, temporary space is allocated from the heap.
</ol>








|







111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
of the [bytecode engine].  By omitting this interface, a single conditional
is removed from the inner loop of the [bytecode engine], helping SQL statements
to run slightly faster.

<li><p><b>[SQLITE_OMIT_SHARED_CACHE]</b>.
Omitting the possibility of using [shared cache] allows many conditionals
in performance-critical sections of the code to be eliminated.  This can
give a noticeable improvement in performance.

<li><p><b>[SQLITE_USE_ALLOCA]</b>.
Make use of alloca() for dynamically allocating temporary stack space for 
use within a single function, on systems that support alloca().  Without
this option, temporary space is allocated from the heap.
</ol>

Changes to pages/dbstat.in.

129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
</codeblock>

<tcl>hd_fragment {dbstatagg} {DBSTAT aggregated mode}</tcl>
<h1>Aggregated Data</h1>

<p>
Beginning with SQLite version 3.31.0 ([dateof:3.31.0]), the DBSTAT table
has a new [hidden column] named "aggregate", which if constrainted to be
TRUE will cause DBSTAT to generate one row per btree in the database,
rather than one row per page.  When running in aggregated mode, the 
"path", "pagetype", and "pgoffset" columns are always NULL and the
"pageno" column holds the number of pages in the entire btree, rather
than the number of the page that corresponds to the row.

<p>







|







129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
</codeblock>

<tcl>hd_fragment {dbstatagg} {DBSTAT aggregated mode}</tcl>
<h1>Aggregated Data</h1>

<p>
Beginning with SQLite version 3.31.0 ([dateof:3.31.0]), the DBSTAT table
has a new [hidden column] named "aggregate", which if constrained to be
TRUE will cause DBSTAT to generate one row per btree in the database,
rather than one row per page.  When running in aggregated mode, the 
"path", "pagetype", and "pgoffset" columns are always NULL and the
"pageno" column holds the number of pages in the entire btree, rather
than the number of the page that corresponds to the row.

<p>

Changes to pages/docsdata.tcl.

82
83
84
85
86
87
88






89
90
91
92
93
94
95
}
doc {Aggregate SQL Functions} {lang_aggfunc.html} {
  General-purpose built-in aggregate SQL functions.
}
doc {Date and Time SQL Functions} {lang_datefunc.html} {
  SQL functions for manipulating dates and times.
}






doc {System.Data.SQLite} {http://system.data.sqlite.org/} {
  C#/.NET bindings for SQLite
}
doc {Tcl API} {tclsqlite.html} {
  A description of the TCL interface bindings for SQLite.
}
doc {DataTypes} {datatype3.html} {







>
>
>
>
>
>







82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
}
doc {Aggregate SQL Functions} {lang_aggfunc.html} {
  General-purpose built-in aggregate SQL functions.
}
doc {Date and Time SQL Functions} {lang_datefunc.html} {
  SQL functions for manipulating dates and times.
}
doc {Window Functions} {windowfunctions.html} {
  SQL Window functions.
}
doc {Generated Columns} {gencol.html} {
  Stored and virtual columns in table definitions.
}
doc {System.Data.SQLite} {http://system.data.sqlite.org/} {
  C#/.NET bindings for SQLite
}
doc {Tcl API} {tclsqlite.html} {
  A description of the TCL interface bindings for SQLite.
}
doc {DataTypes} {datatype3.html} {

Changes to pages/lang.in.

993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
and 3.7.9 use the legacy schema format by default.  The newer schema format is
used by default in version 3.7.10 ([dateof:3.7.10]) and later.
^The [legacy_file_format pragma] can be used to change set the specific
behavior for any version of SQLite.</p>

<p>The NULLS FIRST and NULLS LAST predicates are not supported
for indexes.  For [sort order|sorting purposes], SQLite considers NULL values 
to be smaller than all other values.  Hences NULL values always appear at
the beginning of an ASC index and at the end of a DESC index.</p>

<tcl>hd_fragment collidx {COLLATE}</tcl>
<p>^The COLLATE clause optionally following each column name
or expression defines a
collating sequence used for text entries in that column.
^The default collating







|







993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
and 3.7.9 use the legacy schema format by default.  The newer schema format is
used by default in version 3.7.10 ([dateof:3.7.10]) and later.
^The [legacy_file_format pragma] can be used to change set the specific
behavior for any version of SQLite.</p>

<p>The NULLS FIRST and NULLS LAST predicates are not supported
for indexes.  For [sort order|sorting purposes], SQLite considers NULL values 
to be smaller than all other values.  Hence NULL values always appear at
the beginning of an ASC index and at the end of a DESC index.</p>

<tcl>hd_fragment collidx {COLLATE}</tcl>
<p>^The COLLATE clause optionally following each column name
or expression defines a
collating sequence used for text entries in that column.
^The default collating

Changes to pages/quirks.in.

89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
then it will fail when moved to another database that uses a more rigid
and unforgiving type enforcement policy.

<p>
Flexible typing is considered a feature of SQLite, not a bug.
Nevertheless, we recognize that this feature does sometimes cause
confusion and pain for developers who are acustomed to working with
other databases that are more judgemental with regard to data types.
In retrospect, perhaps it would have been better if SQLite had merely
implemented an ANY datatype so that developers could explicitly state
when they wanted to use flexible typing, rather than making flexible
typing the default.
But that is not something that can be changed now without breaking
the millions of applications and trillions of database files that 
already use SQLite's flexible typing feature.







|







89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
then it will fail when moved to another database that uses a more rigid
and unforgiving type enforcement policy.

<p>
Flexible typing is considered a feature of SQLite, not a bug.
Nevertheless, we recognize that this feature does sometimes cause
confusion and pain for developers who are acustomed to working with
other databases that are more judgmental with regard to data types.
In retrospect, perhaps it would have been better if SQLite had merely
implemented an ANY datatype so that developers could explicitly state
when they wanted to use flexible typing, rather than making flexible
typing the default.
But that is not something that can be changed now without breaking
the millions of applications and trillions of database files that 
already use SQLite's flexible typing feature.

Changes to pages/security.in.

118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
...
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160

<ol>
<li value="7"><p>
If the application includes any [custom SQL functions] or 
[custom virtual tables] that have side effects or that might leak
privileged information, then the application should use one or more
of the techniques below to prevent a maliciously crafted database
schema from surreptiously running those SQL functions and/or
virtual tables for neferious purposes:
<ol type="a">
<li> Invoke [sqlite3_db_config](db,[SQLITE_DBCONFIG_TRUSTED_SCHEMA],0,0)
     on each [database connection] as soon as it is opened.
<li> Run the [PRAGMA trusted_schema=OFF] statement on each database connection
     as soon as it is opened.
<li> Compile SQLite using the [-DSQLITE_TRUSTED_SCHEMA=0] compile-time option.
<li> Disable the surreptious use of custom SQL functions and virtual tables
     by setting the [SQLITE_DIRECTONLY] flag on all custom SQL functions and
     the [SQLITE_VTAB_DIRECTONLY] flag on all custom virtual tables.
</ol>
</li>

<li><p>
If the application does not use triggers or views, consider disabling the
................................................................................
</p>
</ol>

<p>
For reading database files that are unusually high-risk, such as database
files that are received from remote machines, and possibly from anonymous
contributors, the following extra precautions
might be justifed.  These added defenses come with performance costs,
however, and so are probably not appropriate in every situation:

<ol>
<li value="9"><p>
Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database
as the first SQL statement after opening the database files and
prior to running any other SQL statements.  Reject and refuse to







|
|






|







 







|







118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
...
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160

<ol>
<li value="7"><p>
If the application includes any [custom SQL functions] or 
[custom virtual tables] that have side effects or that might leak
privileged information, then the application should use one or more
of the techniques below to prevent a maliciously crafted database
schema from surreptitiously running those SQL functions and/or
virtual tables for nefarious purposes:
<ol type="a">
<li> Invoke [sqlite3_db_config](db,[SQLITE_DBCONFIG_TRUSTED_SCHEMA],0,0)
     on each [database connection] as soon as it is opened.
<li> Run the [PRAGMA trusted_schema=OFF] statement on each database connection
     as soon as it is opened.
<li> Compile SQLite using the [-DSQLITE_TRUSTED_SCHEMA=0] compile-time option.
<li> Disable the surreptitious use of custom SQL functions and virtual tables
     by setting the [SQLITE_DIRECTONLY] flag on all custom SQL functions and
     the [SQLITE_VTAB_DIRECTONLY] flag on all custom virtual tables.
</ol>
</li>

<li><p>
If the application does not use triggers or views, consider disabling the
................................................................................
</p>
</ol>

<p>
For reading database files that are unusually high-risk, such as database
files that are received from remote machines, and possibly from anonymous
contributors, the following extra precautions
might be justified.  These added defenses come with performance costs,
however, and so are probably not appropriate in every situation:

<ol>
<li value="9"><p>
Run [PRAGMA integrity_check] or [PRAGMA quick_check] on the database
as the first SQL statement after opening the database files and
prior to running any other SQL statements.  Reject and refuse to