Documentation Source Text

<li>Added the "win32-none" VFS, analogous to the "unix-none" VFS, that works like
    the default "win32" VFS except that it ignores all file locks.
<li>The query planner uses a full scan of a [partial index] instead of a 
    full scan of the main table, in cases where that makes sense.
<li>Allow [table-valued functions] to appear on the right-hand side of an [IN operator].
<li>Created the [dbhash.exe] command-line utility.
<li>Added two new C-language interfaces: [sqlite3_expanded_sql()] and
    [sqlite3_trace_v2()].

<li>Added the [json_quote()] SQL functio to [the json1 extension].
<p><b>Bug Fixes:</b>
<li>Fix the [ALTER TABLE] command so that it does not corrupt [descending indexes]
    when adding a column to a [legacy_file_format|legacy file format] database.  Ticket
    [https://www.sqlite.org/src/info/f68bf68513a1c15f|f68bf68513a1c15f]
<li>Fix a NULL-pointer dereference/crash that could occurs when a transitive WHERE
    clause references a non-existent collating sequence.  Ticket
    [https://www.sqlite.org/src/info/e8d439c77685eca6|e8d439c77685eca6].

<li>Added the "win32-none" VFS, analogous to the "unix-none" VFS, that works like
    the default "win32" VFS except that it ignores all file locks.
<li>The query planner uses a full scan of a [partial index] instead of a 
    full scan of the main table, in cases where that makes sense.
<li>Allow [table-valued functions] to appear on the right-hand side of an [IN operator].
<li>Created the [dbhash.exe] command-line utility.
<li>Added two new C-language interfaces: [sqlite3_expanded_sql()] and
    [sqlite3_trace_v2()].  These new interfaces subsume the functions of
    [sqlite3_trace()] and [sqlite3_profile()] which are now deprecated.
<li>Added the [json_quote()] SQL function to [the json1 extension].
<p><b>Bug Fixes:</b>
<li>Fix the [ALTER TABLE] command so that it does not corrupt [descending indexes]
    when adding a column to a [legacy_file_format|legacy file format] database.  Ticket
    [https://www.sqlite.org/src/info/f68bf68513a1c15f|f68bf68513a1c15f]
<li>Fix a NULL-pointer dereference/crash that could occurs when a transitive WHERE
    clause references a non-existent collating sequence.  Ticket
    [https://www.sqlite.org/src/info/e8d439c77685eca6|e8d439c77685eca6].

</tcl>
</table></center></blockquote>

<tcl>hd_fragment howtocompile</tcl>
<h1>Compiling the JSON1 Extension</h1>

<p>
The [loadable extensions] documentation contains instructions on 
how to [compile loadable extensions] as shared libraries.  The
techniques described there work fine for the json1 module.

<p>
The json1 source code is included with the SQLite [amalgamation], though
it is turned off by default.  Add the [-DSQLITE_ENABLE_JSON1] compile-time
option to enable the json1 extension that is built into the [amalgamation].

<h1>Interface Overview</h1>

<p>
The json1 extension (currently) stores JSON as ordinary text.

................................................................................
<p>
Backwards compatibility constraints mean that SQLite is only able to
store values that are NULL, integers, floating-point numbers, text,
and BLOBs.  It is not possible to add a sixth "JSON" type.

<p>
The json1 extension does not (currently) support a binary encoding
of JSON.  Experiments have so far been unable to find a binary encoding
that is significantly smaller or faster than a plain text encoding.
(The present implementation parses JSON text at over 300 MB/s.)
All json1 functions currently throw an error if any of their
arguments are BLOBs because BLOBs are reserved
for a future enhancement in which BLOBs will store the binary encoding
for JSON.

................................................................................
<p>
For functions that accept JSON as their first argument, that argument
can be a JSON object, array, number, string, or null.  SQLite numeric
values and NULL values are interpreted as JSON numbers and nulls, respectively.
SQLite text values can be understood as JSON objects, arrays, or strings.
If an SQLite text value that is not a well-formed JSON object, array, or
string is passed into json1 function, that function will usually throw
an error.  (An exception is the json_valid(X) 
function which returns 1 if X is well-formed JSON and 0 if it is not.)

<p>
For the purposes of determining validity, leading and trailing whitespace
on JSON inputs is ignored.  Interior whitespace is also ignored, in accordance
with the JSON spec.  These routines accept exactly the 
[http://www.rfc-editor.org/rfc/rfc7159.txt | rfc-7159 JSON syntax]
&mdash; no more and no less.

</tcl>
</table></center></blockquote>

<tcl>hd_fragment howtocompile</tcl>
<h1>Compiling the JSON1 Extension</h1>

<p>
The [loadable extensions] documentation describes
how to [compile loadable extensions] as shared libraries.  The
techniques described there work fine for the json1 module.

<p>
The json1 source code is included with the SQLite [amalgamation], though
it is disabled by default.  Add the [-DSQLITE_ENABLE_JSON1] compile-time
option to enable the json1 extension that is built into the [amalgamation].

<h1>Interface Overview</h1>

<p>
The json1 extension (currently) stores JSON as ordinary text.

................................................................................
<p>
Backwards compatibility constraints mean that SQLite is only able to
store values that are NULL, integers, floating-point numbers, text,
and BLOBs.  It is not possible to add a sixth "JSON" type.

<p>
The json1 extension does not (currently) support a binary encoding
of JSON.  Experiments have been unable to find a binary encoding
that is significantly smaller or faster than a plain text encoding.
(The present implementation parses JSON text at over 300 MB/s.)
All json1 functions currently throw an error if any of their
arguments are BLOBs because BLOBs are reserved
for a future enhancement in which BLOBs will store the binary encoding
for JSON.

................................................................................
<p>
For functions that accept JSON as their first argument, that argument
can be a JSON object, array, number, string, or null.  SQLite numeric
values and NULL values are interpreted as JSON numbers and nulls, respectively.
SQLite text values can be understood as JSON objects, arrays, or strings.
If an SQLite text value that is not a well-formed JSON object, array, or
string is passed into json1 function, that function will usually throw
an error.  (Exceptions to this rule are [json_valid()] and
[json_quote()].)

<p>
For the purposes of determining validity, leading and trailing whitespace
on JSON inputs is ignored.  Interior whitespace is also ignored, in accordance
with the JSON spec.  These routines accept exactly the 
[http://www.rfc-editor.org/rfc/rfc7159.txt | rfc-7159 JSON syntax]
&mdash; no more and no less.