Documentation Source Text

Check-in [9d6e96fd8f]
Login

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

Overview
Comment:Merge changes from the 3.26.0 release branch.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256:9d6e96fd8f1eb54572452fbf36006df7c2413fd693b43788ef02b033985ca02c
User & Date: drh 2019-02-07 13:47:38
Context
2019-02-07
13:59
Add back the sponsors section to the front page. check-in: 3b7ad43873 user: drh tags: trunk
13:47
Merge changes from the 3.26.0 release branch. check-in: 9d6e96fd8f user: drh tags: trunk
13:42
Add news for 3.27.0 check-in: 7a25788e4c user: drh tags: trunk
2019-01-29
18:59
Fix a typo in the date-time function documentation. Leaf check-in: 0866c95aaf user: drh tags: branch-3.26
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/assert.in.

199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
running off the end of the linked list in case there is an error in some
other part of the code that has corrupted the linked list.

<p>
An ALWAYS(X) or NEVER(X) sometimes verifies pre-conditions that are
subject to change if other parts of the code are modified in
subtle ways.  At [https://sqlite.org/src/artifact/18a53540aa3?ln=5512-5516]
we have a case test for two pre-conditions that are true only because
of the limited scope of use of the sqlite3BtreeRowCountEst() function.
Future enhancements to SQLite might use sqlite3BtreeRowCountEst() in
new ways where those preconditions no longer hold, and the NEVER()
macros will quickly alert the developers to that fact when the
situation arises.  But if, for some reason, the pre-conditions are
not satisfied in a release build, the program will still behave sanely
and will not do an undefined memory access.

<p>
The testcase() macro is often used to verify that boundary
cases of an inequality comparison are checked.  For example, at
[https://sqlite.org/src/artifact/18a53540aa3?ln=5766].  These
kind of checks help to prevent off-by-one errors.







|













199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
running off the end of the linked list in case there is an error in some
other part of the code that has corrupted the linked list.

<p>
An ALWAYS(X) or NEVER(X) sometimes verifies pre-conditions that are
subject to change if other parts of the code are modified in
subtle ways.  At [https://sqlite.org/src/artifact/18a53540aa3?ln=5512-5516]
we have a test for two pre-conditions that are true only because
of the limited scope of use of the sqlite3BtreeRowCountEst() function.
Future enhancements to SQLite might use sqlite3BtreeRowCountEst() in
new ways where those preconditions no longer hold, and the NEVER()
macros will quickly alert the developers to that fact when the
situation arises.  But if, for some reason, the pre-conditions are
not satisfied in a release build, the program will still behave sanely
and will not do an undefined memory access.

<p>
The testcase() macro is often used to verify that boundary
cases of an inequality comparison are checked.  For example, at
[https://sqlite.org/src/artifact/18a53540aa3?ln=5766].  These
kind of checks help to prevent off-by-one errors.

Changes to pages/codeofethics.in.

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
specific technical requirements was inserted in the place of
the old name.

<p>
This document is still sometimes used as a "Code of Conduct" on supplier
registration forms.  But it is not a Code of Conduct in the same sense
that many communities mean a Code of Conduct.  Rather,
this document describes the ethical principals upon
which SQLite is based.  Another way to look at this document is
as a succinct description of the SQLite Founder's idea of what it
means to be "virtuous".

<p>
Readers can also interpret this document as a primer on the
world-view of the SQLite Founder, to help them better understand







|







17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
specific technical requirements was inserted in the place of
the old name.

<p>
This document is still sometimes used as a "Code of Conduct" on supplier
registration forms.  But it is not a Code of Conduct in the same sense
that many communities mean a Code of Conduct.  Rather,
this document describes the ethical principles upon
which SQLite is based.  Another way to look at this document is
as a succinct description of the SQLite Founder's idea of what it
means to be "virtuous".

<p>
Readers can also interpret this document as a primer on the
world-view of the SQLite Founder, to help them better understand

Changes to pages/lang.in.

3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
localtime_r() C function normally only works for years
between 1970 and 2037. For dates outside this range, SQLite 
attempts to map the year into an equivalent year within 
this range, do the calculation, then map the year back.)^</p>


<p>^(These functions only work for dates between 0000-01-01 00:00:00
and 9999-12-31 23:59:59 (julidan day numbers 1721059.5 through 5373484.5).)^
For dates outside that range, the results of these
functions are undefined.</p>

<p>Non-Vista Windows platforms only support one set of DST rules. 
Vista only supports two. Therefore, on these platforms, 
historical DST calculations will be incorrect. 
For example, in the US, in 2007 the DST rules changed. 







|







3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
localtime_r() C function normally only works for years
between 1970 and 2037. For dates outside this range, SQLite 
attempts to map the year into an equivalent year within 
this range, do the calculation, then map the year back.)^</p>


<p>^(These functions only work for dates between 0000-01-01 00:00:00
and 9999-12-31 23:59:59 (julian day numbers 1721059.5 through 5373484.5).)^
For dates outside that range, the results of these
functions are undefined.</p>

<p>Non-Vista Windows platforms only support one set of DST rules. 
Vista only supports two. Therefore, on these platforms, 
historical DST calculations will be incorrect. 
For example, in the US, in 2007 the DST rules changed. 

Changes to pages/pragma.in.

1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
    database connection.</p>)^
}

Pragma database_list {
    <p>^(<b>PRAGMA database_list;</b></p>
    <p>This pragma works like a query to return one row for each database
    attached to the current database connection.)^
    ^(The second column is the "main" for the main database file, "temp"
    for the database file used to store TEMP objects, or the name of the
    ATTACHed database for other database files.)^
    ^(The third column is the name of the database file itself, or an empty
    string if the database is not associated with a file.)^</p>
}

Pragma foreign_key_list {







|







1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
    database connection.</p>)^
}

Pragma database_list {
    <p>^(<b>PRAGMA database_list;</b></p>
    <p>This pragma works like a query to return one row for each database
    attached to the current database connection.)^
    ^(The second column is "main" for the main database file, "temp"
    for the database file used to store TEMP objects, or the name of the
    ATTACHed database for other database files.)^
    ^(The third column is the name of the database file itself, or an empty
    string if the database is not associated with a file.)^</p>
}

Pragma foreign_key_list {

Changes to pages/security.in.

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  {defense against dark arts}</tcl>
<fancy_format>

<h1>SQLite Always Validates Its Inputs</h1>

<p>
SQLite should never crash, overflow a buffer, leak memory,
or exhibit any other harmful behavior, even with presented with
maliciously malformed SQL inputs or database files.  SQLite should
always detect erroneous inputs and raise an error, not crash or
corrupt memory.
Any malfunction caused by an SQL input or database file
is considered a serious bug and will be promptly addressed when
brought to the attention of the SQLite developers.  SQLite is
extensively fuzz-tested to help ensure that it is resistant







|







3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  {defense against dark arts}</tcl>
<fancy_format>

<h1>SQLite Always Validates Its Inputs</h1>

<p>
SQLite should never crash, overflow a buffer, leak memory,
or exhibit any other harmful behavior, even when presented with
maliciously malformed SQL inputs or database files.  SQLite should
always detect erroneous inputs and raise an error, not crash or
corrupt memory.
Any malfunction caused by an SQL input or database file
is considered a serious bug and will be promptly addressed when
brought to the attention of the SQLite developers.  SQLite is
extensively fuzz-tested to help ensure that it is resistant