SQLite backwards compat

rg -i "backwards.compat" | sort | uniq

35to36.html:  the SQLite project, most changes are fully backwards compatible.
35to36.html:  version 3.6.0 adds the following backwards compatible changes and
35to36.html:<h2>2.0 Fully Backwards-Compatible Enhancements</h2><p>
about.html:backwards compatibility with the
aff_short.html:     by adding new tables and/or columns, preserving backwards compatibility.
appfileformat.html:and is backwards compatible to its inception in 2004 and which promises
appfileformat.html:tables are preserved, backwards compatibility is maintained.
c3ref/aggregate_count.html:backwards compatibility with older code, these functions continue
c3ref/c_config_covering_index_scan.html:They are retained for backwards compatibility but are now no-ops.
c3ref/experimental.html:backwards compatibility.  At some point in the future, it is possible
c3ref/free_table.html:This is a legacy interface that is preserved for backwards compatibility.
c3ref/mprintf.html:backwards compatibility.  Note also that sqlite3_snprintf()
c3ref/prepare.html:are retained for backwards compatibility, but their use is discouraged.
c3ref/temp_directory.html:that exists for backwards compatibility of legacy applications and should
capi3ref.html:are retained for backwards compatibility, but their use is discouraged.
capi3ref.html:backwards compatibility with older code, these functions continue
capi3ref.html:backwards compatibility.  At some point in the future, it is possible
capi3ref.html:backwards compatibility.  Note also that sqlite3_snprintf()
capi3ref.html:that exists for backwards compatibility of legacy applications and should
capi3ref.html:They are retained for backwards compatibility but are now no-ops.
capi3ref.html:This is a legacy interface that is preserved for backwards compatibility.
carray.html:method is still supported for backwards compatibility, however new
changes.html:          backwards-compatibly work with existing databases created
changes.html:     change should be fully backwards compatible, though it might cause
changes.html:     for backwards compatibility.
changes.html:    be fully backwards compatible.</li>
changes.html:    in a way that is backwards compatible but which might cause
changes.html:    still maintaining backwards compatibility) in two ways:
changes.html:    way that is backwards compatible but which might cause warnings in new
changes.html:<li>Fix a backwards compatibility problem in version 3.12.0 and 3.12.1:
changes.html:<p><b>Backwards Compatibility:</b>
cintro.html:  backwards compatibility.  But <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> provides a much
cli.html:that are retained for backwards compatibility.</p>
climode.html:  backwards compatibility.
compile.html:  compatibility.  However, the backwards compatibility break may be only
compile.html:  For backwards compatibility with older versions of SQLite that lack
deterministic.html:an historical bug and the desire to maintain backwards compatibility,
different.html:  stable and backwards compatible, so newer versions of SQLite can
docs.html:  for backwards compatibility.
docs.html:<li><a class='sh_link' href='formatchng.html'>Backwards Compatibility</a>
docs.html:<li><a onclick='showhide(10)'><span class='sh_mark' id='sh_mark_10'>&#x25ba;</span> Upgrading SQLite, Backwards Compatibility</a>
faq.html:  of foreign key constraints is turned off by default (for backwards compatibility).
fileformat.html:not really needed any more, but is retained for backwards compatibility.</p>
fileformat2.html:not really needed any more, but is retained for backwards compatibility.</p>
foreignkeys.html:    (for backwards compatibility),
formatchng.html:By "backwards compatible" we mean that
formatchng.html:the file format has been fully backwards compatible.
fts3.html:   a bug, but cannot be fixed without creating backwards compatibility
fts3.html:  For reasons of backwards compatibility, the "automerge=1" command sets
fts5.html:  without creating backwards compatibility problems. If this option is set to
fts5.html:<p> Unless backwards compatibility is required, new code should prefer
fts5.html:<p><b>Backwards Compatibility Warning:</b>
json1.html:Backwards compatibility constraints mean that SQLite is only able to
json1.html:For backwards compatibility, the <a href="json1.html#jvalid">json_valid(X)</a> function without a
keyword_index.html:<li> <a href="wal.html#bkwrds">WAL backwards compatibility</a> </li>
lang_analyze.html:value for the analysis limit is 0 for backwards compatibility.
lang_expr.html:For backwards compatibility, the "0x" hexadecimal integer
lang_expr.html:the sake of backwards compatibility, the TRUE and FALSE identifiers refer
lts.html:fully backwards compatible.
news.html:<p>Yikes!  The 3.12.0 and 3.12.1 releases contain a backwards compatibility bug!
oldnews.html:  default for backwards compatibility and must be turned on using
oldnews.html:  URI filenames are disabled by default (for backwards compatibility) but
oldnews.html:  website.  Version 3.1.0 is fully backwards compatible with the 3.0 series
oldnews.html:  website.  Version 3.1.1 is fully backwards compatible with the 3.0 series
onefile.html:going back to 2004-06-18.  This is "backwards compatibility".
onefile.html:The developers promise to maintain backwards compatibility of
pragma.html:      for backwards compatibility.
pragma.html:    <p><i>Backwards compatibility note:</i>
pragma.html:    <p>In order to maintain backwards compatibility, this setting is
pragma.html:    for backwards compatibility only.  New applications
pragma.html:    releases of SQLite. There is no guarantee of backwards compatibility.
queryplanner-ng.html:available, for backwards compatibility.  But you shouldn't use
quirks.html:But for backwards compatibility, if there are columns named TRUE or
quirks.html:The ability to use keywords as identifiers promotes backwards compatibility.
rowvalue.html:</p><h1 id="backwards_compatibility"><span>4. </span>Backwards Compatibility</h1>
rowvalue.html:<div class="fancy-toc1"><a href="#backwards_compatibility">4. Backwards Compatibility</a></div>
rsync.html:</p><h2 id="backwards_compatibility_issues"><span>4.1. </span>Backwards-Compatibility Issues</h2>
rsync.html:<div class="fancy-toc2"><a href="#backwards_compatibility_issues">4.1. Backwards-Compatibility Issues</a></div>
rtree.html:interface that is supported for backwards compatibility.
sharedcache.html:a <a href="uri.html">URI filename</a>.  For backwards compatibility, shared cache is always
sharedcache.html:in SQLite, to insure full backwards compatibility.  However, the use of
shortnames.html:filename restrictions for backwards compatibility, or due
stricttables.html:<h1 id="backwards_compatibility"><span>4. </span>Backwards Compatibility</h1>
uri.html:<h1 id="backwards_compatibility"><span>2. </span>Backwards Compatibility</h1>
uri.html:In order to maintain full backwards compatibility for legacy applications,
vtab.html:backwards compatibility.
wal.html:<div class="fancy-toc1"><a href="#backwards_compatibility">10. Backwards Compatibility</a></div>
wal.html:<h1 id="backwards_compatibility"><span>10. </span>Backwards Compatibility</h1>