Documentation Source Text

<li>Fix a bug in [R-Tree extension], introduced in the previous release,
    that can cause an
    incorrect results for queries that use the rowid of the R-Tree on the
    left-hand side of an [IN operator].
    Ticket [http://www.sqlite.org/src/info/d2889096e7bdeac6|d2889096e7bdeac6].
<li>Fix the [sqlite3_stmt_busy()] interface so that it gives the correct answer
    for [ROLLBACK] statements that have been stepped but never reset.




<li>CSV output from the [command-line shell] now always uses CRNL for the
    row separator and avoids inserting CR in front of NLs contained in
    data.
<li>Fix a [column affinity] problem with the [IN operator].
    Ticket [http://www.sqlite.org/src/info/9a8b09f8e6|9a8b09f8e6].
<li>Fix the [ANALYZE] command so that it adds correct samples for
    [WITHOUT ROWID] tables in the [sqlite_stat4] table.

<li>Fix a bug in [R-Tree extension], introduced in the previous release,
    that can cause an
    incorrect results for queries that use the rowid of the R-Tree on the
    left-hand side of an [IN operator].
    Ticket [http://www.sqlite.org/src/info/d2889096e7bdeac6|d2889096e7bdeac6].
<li>Fix the [sqlite3_stmt_busy()] interface so that it gives the correct answer
    for [ROLLBACK] statements that have been stepped but never reset.
<li>Fix a bug in that would cause a null pointer to be dereferenced
    if a column with a DEFAULT that is an aggregate function tried to usee its
    DEFAULT.
    Ticket [http://www.sqlite.org/src/info/3a88d85f36704eebe1|3a88d85f36704eebe1]
<li>CSV output from the [command-line shell] now always uses CRNL for the
    row separator and avoids inserting CR in front of NLs contained in
    data.
<li>Fix a [column affinity] problem with the [IN operator].
    Ticket [http://www.sqlite.org/src/info/9a8b09f8e6|9a8b09f8e6].
<li>Fix the [ANALYZE] command so that it adds correct samples for
    [WITHOUT ROWID] tables in the [sqlite_stat4] table.

doc {VDBE Tutorial} {vdbe.html} {
  The VDBE is the subsystem within SQLite that does the actual work of
  executing SQL statements.  This page describes the principles of operation
  for the VDBE in SQLite version 2.7.  This is essential reading for anyone
  who want to modify the SQLite sources.
}
doc {SQLite Version 3} {version3.html} {
  A summary of of the changes between SQLite version 2.8 and SQLite version 3.0.
}
doc {Version 3 C/C++ API} {capi3.html} {
  A summary of of the API related changes between SQLite version 2.8 and 
  SQLite version 3.0. 
}
doc {Speed Comparison} {speed.html} {
  The speed of version 2.7.6 of SQLite is compared against PostgreSQL and
  MySQL.
}

</tcl>
</table>

doc {VDBE Tutorial} {vdbe.html} {
  The VDBE is the subsystem within SQLite that does the actual work of
  executing SQL statements.  This page describes the principles of operation
  for the VDBE in SQLite version 2.7.  This is essential reading for anyone
  who want to modify the SQLite sources.
}
doc {SQLite Version 3} {version3.html} {
  A summary of the changes between SQLite version 2.8 and SQLite version 3.0.
}
doc {Version 3 C/C++ API} {capi3.html} {
  A summary of the API related changes between SQLite version 2.8 and 
  SQLite version 3.0. 
}
doc {Speed Comparison} {speed.html} {
  The speed of version 2.7.6 of SQLite is compared against PostgreSQL and
  MySQL.
}

</tcl>
</table>

In other words, this article provides ideas and insights, not turnkey
solutions.</p>

<h2>Amalgamation Versus Individual Source Files</h2> 

<p>SQLite is built from over one hundred of files of C code and script
spread across multiple directories.  The implementation of SQLite is pure
ANSI-C, but many of the C-language source code files are either either
generated or transformed by auxiliary C programs and AWK, SED, and TCL 
scripts prior to being incorporated into the finished SQLite library.
Building the necessary C programs and transforming and/or creating the
C-language source code for SQLite is a complex process.</p>

<p>To simplify matters, SQLite is also available as a pre-packaged
[amalgamation] source code file: <b>sqlite3.c</b>.  The amalgamation is

In other words, this article provides ideas and insights, not turnkey
solutions.</p>

<h2>Amalgamation Versus Individual Source Files</h2> 

<p>SQLite is built from over one hundred of files of C code and script
spread across multiple directories.  The implementation of SQLite is pure
ANSI-C, but many of the C-language source code files are either
generated or transformed by auxiliary C programs and AWK, SED, and TCL 
scripts prior to being incorporated into the finished SQLite library.
Building the necessary C programs and transforming and/or creating the
C-language source code for SQLite is a complex process.</p>

<p>To simplify matters, SQLite is also available as a pre-packaged
[amalgamation] source code file: <b>sqlite3.c</b>.  The amalgamation is