Documentation Source Text

    and [sqlite3_snapshot_free()] interfaces.  These are subject to change or removal in
    a subsequent release.
<li>Enhance the ['utc' modifier] in the [date and time functions] so that it is a no-op if
    the date/time is known to already be in UTC.  (This is not a compatibility break since
    the behavior has long been documented as "undefined" in that case.)
<li>Added the [json_group_array()] and [json_group_object()] SQL functions in the
    [json] extension.

<li>Many small performance optimizations.
<p><b>Portability enhancements:</b>
<li>Work around a sign-exension bug in the optimizer of the HP C compiler on HP/UX.
    [https://www.sqlite.org/src/fdiff?sbs=1&v1=869c95b0fc73026d&v2=232c242a0ccb3d67|(details)]
<p><b>Enhancements to the [command-line shell]:</b>
<li>Added the ".changes ON|OFF" and ".vfsinfo" [dot-commands].
<li>Translate between MBCS and UTF8 when

    and [sqlite3_snapshot_free()] interfaces.  These are subject to change or removal in
    a subsequent release.
<li>Enhance the ['utc' modifier] in the [date and time functions] so that it is a no-op if
    the date/time is known to already be in UTC.  (This is not a compatibility break since
    the behavior has long been documented as "undefined" in that case.)
<li>Added the [json_group_array()] and [json_group_object()] SQL functions in the
    [json] extension.
<li>Added the [SQLITE_LIKE_DOESNT_MATCH_BLOBS] compile-time option.
<li>Many small performance optimizations.
<p><b>Portability enhancements:</b>
<li>Work around a sign-exension bug in the optimizer of the HP C compiler on HP/UX.
    [https://www.sqlite.org/src/fdiff?sbs=1&v1=869c95b0fc73026d&v2=232c242a0ccb3d67|(details)]
<p><b>Enhancements to the [command-line shell]:</b>
<li>Added the ".changes ON|OFF" and ".vfsinfo" [dot-commands].
<li>Translate between MBCS and UTF8 when

  the base-2 logarithm of the number of terms in the right-hand side of the
  MATCH operator.  However, for [phrase queries] and [NEAR queries] the
  search tree depth is linear in the number of right-hand side terms.
  So the default depth limit of 12 is sufficient for up to 4095 ordinary
  terms on a MATCH, it is only sufficient for 11 or 12 phrase or NEAR
  terms.  Even so, the default is more than enough for most application.
}




















COMPILE_OPTION {SQLITE_MAX_MMAP_SIZE=<i>N</i>} {
  This macro sets a hard upper bound on the amount of address space that
  can be used by any single database for memory-mapped I/O.
  Setting this value to 0 completely disables memory-mapped I/O and
  causes logic associated with memory-mapped I/O to be omitted from the
  build.  This option does change the default memory-mapped I/O address

  the base-2 logarithm of the number of terms in the right-hand side of the
  MATCH operator.  However, for [phrase queries] and [NEAR queries] the
  search tree depth is linear in the number of right-hand side terms.
  So the default depth limit of 12 is sufficient for up to 4095 ordinary
  terms on a MATCH, it is only sufficient for 11 or 12 phrase or NEAR
  terms.  Even so, the default is more than enough for most application.
}

COMPILE_OPTION {SQLITE_LIKE_DOESNT_MATCH_BLOBS} {
  This compile-time option causes the [LIKE] operator to always return 
  False if either operand is a BLOB.  The default behavior of [LIKE] 
  is that BLOB operands are cast to TEXT before the comparison is done.
  <p>
  This compile-time option makes SQLite run more efficiently when processing
  queries that use the [LIKE] operator, at the expense of breaking backwards
  compatibility.  However, the backwards compatibility break may be only
  a technicality.  There was a long-standing bug in the [LIKE] processing logic
  (see [https://www.sqlite.org/src/info/05f43be8fdda9f]) that caused it to
  misbehavior for BLOB operands and nobody observed that bug in nearly
  10 years of active use.  So for more users, it is probably safe to
  enable this compile-time option and thereby save a little CPU time
  on LIKE queries.
  <p>
  This compile-time option affects the SQL [LIKE] operator only and has
  no impact on the [sqlite3_strlike()] C-language interface.
}

COMPILE_OPTION {SQLITE_MAX_MMAP_SIZE=<i>N</i>} {
  This macro sets a hard upper bound on the amount of address space that
  can be used by any single database for memory-mapped I/O.
  Setting this value to 0 completely disables memory-mapped I/O and
  causes logic associated with memory-mapped I/O to be omitted from the
  build.  This option does change the default memory-mapped I/O address