Documentation Source Text

set nChng 0
proc chng {date desc {options {}}} {
  global nChng aChng
  set aChng($nChng) [list $date $desc $options]
  incr nChng
}

chng {2016-01-06 (3.10.0)} {
<p><b>General improvements:</b>
<li>Added support for [LIKE], [GLOB], and [REGEXP] operators on [virtual tables].
<li>Added the [colUsed field] to [sqlite3_index_info] for use by
    the [sqlite3_module.xBestIndex] method.
<li>Enhance the [PRAGMA cache_spill] statement to accept a 32-bit integer
    parameter which is the threshold below which cache spilling is prohibited.
<li>On unix, if a symlink to a database file is opened, then the corresponding

    could result in a corrupt index if the index is created on a table
    column that contains both large integers and floating point values
    of similar magnitude.  Ticket 
    [https://www.sqlite.org/src/tktview?name=38a97a87a6|38a97a87a6].
<li>Fix an infinite-loop in the query planner that could occur on
    malformed [common table expressions].
<li>Various bug fixes in the [sqldiff] tool.
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2016-01-06 11:01:07 fd0a50f0797d154fefff724624f00548b5320566"
<li>SHA1 for sqlite3.c: b92ca988ebb6df02ac0c8f866dbf3256740408ac

}

chng {2015-11-03 (3.9.2)} {
<li>Fix the schema parser so that it interprets certain 
    (obscure and ill-formed)
    CREATE TABLE statements the same as legacy.  Fix for ticket
    [https://www.sqlite.org/src/info/ac661962a2aeab3c331|ac661962a2aeab3c331]

heading {SQLite Technical/Design Documentation} {
  These documents are oriented toward describing the internal
  implementation details and operation of SQLite.  
}

doc {How Database Corruption Can Occur} {howtocorrupt.html} {
  SQLite is highly resistant to database corruption.  But application,
  OS, and hardware bugs can still result in corrupt database files.
  This article describes many of the ways that SQLite database files
  can go corrupt.
}

doc {Temporary Files Used By SQLite} {tempfiles.html} {
  SQLite can potentially use many different temporary files when

         {json_array_length}</tcl>
<h3>3.3 The json_array_length() function</h3>

<p>The json_array_length(X) function returns the number of elements
in the JSON array X, or 0 if X is some kind of JSON value other
than an array.  The json_array_length(X,P) locates the array at path P
within X and returns the length of that array, or 0 if path P locates
a element or X other than a JSON array, and NULL if path P does not
locate any element of X.  Errors are thrown if either X is not 
well-formed JSON or if P is not a well-formed path.

<p>Examples:

<tcl>
jexample \

<tr>
<td>json_set()<td align='center'>Yes<td align='center'>Yes
</table></center>

<p>The json_insert(), json_replace(), and json_set() functions always
take an odd number of arguments.  The first argument is always the original
JSON to be edited.  Subsequent arguments occur in pairs with the first
element of each pair being a path and the second element being the value
to insert or replace or set on that path.

<p>Edits occurs sequentially from left to right.  Changes caused by
prior edits can affect the path search for subsequent edits.

<p>If the value of a path/value pair is an SQLite TEXT value, then it
is normally inserted as a quoted JSON string, even if the string looks

  hd_puts "<h3>$date - $title</h3>"
  regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
  regsub -all {[Tt]icket #(\d+)} $txt \
      {<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
  hd_resolve "<blockquote>$txt</blockquote>"
  hd_puts "<hr width=\"50%\">"
}

newsitem {2016-01-06} {Release 3.10.0} {
<p>SQLite [version 3.10.0] is a regularly scheduled maintenance release.
}

newsitem {2015-11-02} {Release 3.9.2} {
<p>SQLite [version 3.9.2] is a patch release fixing two obscure bugs.
(Details: [https://www.sqlite.org/src/tktview?name=8a2adec166|(1)],
[https://www.sqlite.org/src/tktview?name=ac661962a2|(2)]).
Upgrade only if you are having problems.
}

  CREATE VIEW data0_ccc_fts AS SELECT * FROM data_ccc;
}</tcl>
 
<p>
  The data_ccc table may then be populated as normal with the updates intended
  for target database table ccc. The same updates will be read by RBU from
  the data0_ccc_fts view and applied to FTS table ccc_fts. Because
  "data0_ccc_fts" is smaller than "data_ccc", the FTS table will be updated
  first, as required.

<p>
  Cases in which the underlying content table has an explicit INTEGER PRIMARY
  KEY column are slightly more difficult, as the text values stored in the
  ota_control column are slightly different for the FTS index and its
  underlying content table. For the underlying content table, a character

<tcl>hd_keywords {version numbering conventions}</tcl>
<title>Version Numbers in SQLite</title>

<h1>SQLite Version Numbers</h1>

<p>
Beginning with [version 3.9.0] SQLite uses 
[http://semver.org|semantic versioning].
Prior to that time, SQLite employed a version identifier that
contained between two and four numbers.

<h2>The New Version Numbering System (After 2015-10-01)</h2>

<p>
All SQLite releases starting with 3.9.0 use a three-number
"[http://semver.org|semantic version]" of the form X.Y.Z.

[next generation query planner].

<p>
The minor version number Y was historically incremented for new
features and/or new interfaces that did not significantly change
the structure of the code.  The addition of [common table expressions],
[partial indexes], and [indexes on expressions] are all examples of
"minor" changes.  Again, the distinction between "major" and "minor"
is subjective.

<p>
The patch level Z was historically only used for bug-fix releases
that changed only a small number of code lines.