Documentation Source Text

<p>^(In the extreme case where the columns being indexed cover all columns
of the PRIMARY KEY, the index will consist of only the columns being
indexed.  The ex25acde example above demonstrates this.)^  ^Each entry in
the ex25acde index consists of only the columns a, c, d, and e, in that
order.</p>

<p>Each row in ex25ae contains five columns: c, e, d, c, a.  The c
column is repeated since the first occurrance of c has a collating
function of "nocase" and the second has a collating sequence of "binary".
If the c column is not repeated and if the table contains two or more
entries with the same e value and where c differs only in case, then
all of those table entries would correspond to a single entry in the
index, which would break the one-to-one correspondence between the table
and the index.

    <p>The default page cache implemention does not allocate
    the full amount of cache memory all at once.  Cache memory
    is allocated in smaller chunks on an as-needed basis.  The page_cache
    setting is a (suggested) upper bound on the amount of memory that the
    cache can use, not the amount of memory it will use all of the time.
    This is the behavior of the default page cache implementation, but an
    [sqlite3_pcache_methods2 | applicaction defined page cache] is free
    to behave differently if it wants.
}

Pragma case_sensitive_like {
    <p><b>PRAGMA case_sensitive_like = </b><i>boolean</i><b>;</b></p>
    <p>^(The default behavior of the [LIKE] operator is to ignore case
    for ASCII characters. Hence, by default <b>'a' LIKE 'A'</b> is

<p>
SQLite is very flexible with regard to datatypes.

<p>
Some commentators say that SQLite is "weakly typed" and that other
SQL databases are "strongly typed".  We consider these terms to be
inaccurate and perjorative.  We prefer to say that SQLite is "flexibly typed"
and that other SQL databases are "rigidly typed".

<p>
See the [datatype|Datatypes in SQLite Version 3] document for a detailed
discussion of the type system in SQLite.

<p>
The key point is that SQLite is very forgiving of the type of data that
you put into the database.  For example, if a column has a datatype of
"INTEGER" and the application inserts a text string into that column,
SQLite will first try to convert the text string into an integer, just like
every other SQL database engine.  Thus, if one inserts <b>'1234'</b> into
an INTEGER column, that value is converted into an integer 1234 and stored.
But, if you insert a non-numeric string like <b>'wxyz'</b> into an INTEGER
column, unlike other SQL databases, SQLite does not throw an error.  Instead,
SQLite stores the actual string value in the column.

<p>
Similarly, SQLite allows you to store a 2000-character string into a
column of type VARCHAR(50).  Other SQL implementions would either throw
an error or truncate the string.  SQLite stores the entire 2000-character
string with no loss of information and without complaint.

<p>
Where this ends up causing problems is when developers do some initial
coding work using SQLite and get their application working, but then try
to convert to another database like PostgreSQL or SQL Server for deployment.

string literal causes a warning message to be sent to the [error log].
<p>
As of SQLite 3.29.0 ([dateof:3.29.0]) the use of double-quoted
string literals can be disabled at run-time using the
[SQLITE_DBCONFIG_DQS_DDL] and [SQLITE_DBCONFIG_DQS_DML] actions
to [sqlite3_db_config()].  The default settings can be altered
at compile-time using the [-DSQLITE_DQS=<i>N</i>] compile-time
option.  Application developers are encouranged to compile using
-DSQLITE_DQS=0 in order to disable the double-quoted string literal
misfeature by default.  If that is not possible, then disable
double-quoted string literals for individual database connections
using C-code like this:
<blockquote><pre>
sqlite3_db_config(db, SQLITE_DBCONFIG_DQS_DDL, 0, (void*)0);
sqlite3_db_config(db, SQLITE_DBCONFIG_DQS_DML, 0, (void*)0);

[https://sqlite.org/src/timeline|timeline] and in a single
screen I can see a quick summary of all the latest changes,
on all branches.
In a few clicks, I can drill down to see as much detail as I
want.  I can even do this from a phone.

<p>
GitHub and GitLab offer nothing comparible.  The closest I have
found is the [https://github.com/sqlite/sqlite/network|network],
which is slow to render (unless it is already cached), does not 
offer nearly as much details, and scarcely works on mobile.
The [https://github.com/sqlite/sqlite/commits/master|commits] view
of GitHub provides more detail, renders quickly,
and works on mobile, but only shows a single branch at a time,
so I cannot easily know if I've seen all of the recent changes.