Documentation Source Text

#!/usr/bin/tclsh
set usage {Usage:
  hlinkch.tcl <doc_root> <hldb> <html_pages>
}

if {$argc >= 2 && [lindex $argv 0] eq "--url-normalize-log"} {
  set ::iun [open [lindex $argv 1] w]
  incr argc -2
  set $argv [lrange $argv 2 end]
} else { set ::iun "" }

if {$argc < 3} { puts $usage; exit 0 }

set ::doc_root_nom [lindex $argv 0]
set ::drre "^$::doc_root_nom/"
set ::doc_root [file normalize $::doc_root_nom]
set ::doc_rlen [expr [string length $::doc_root] + 1]
set hlink_db [lindex $argv 1]
set argv [lrange $argv 2 end]
incr argc -2
set sdir [file dirname [info script]]
source [file join $sdir search hdom.tcl]

# Normalize input filename to be docroot-relative.
proc finorm {fn} {
  regsub $::drre $fn {} fn
  set fn [file normalize $fn]
  set drix [string first $::doc_root $fn]
  if {$drix != 0} { return $fn }
  return [string range $fn $::doc_rlen end]
}

# Normalize internal URL filename to be docroot-relative.
# Inputs are relative to the source referencing the URL.
# Directories . or .. must be leading for this to work.
proc iunorm {ufn sfn} {
  set rv $ufn
  set sdir [file dirname $sfn]
  if {$sdir eq "."} { set sds [list] } else { set sds [file split $sdir] }
  if {[regexp {^(\.\.?)/(.*)} $ufn _ dd ufnnd]} {
    switch $dd {
      . { set rv [file join {*}$sds $ufnnd] }
      .. {
        set rv [file join {*}[lrange $sds 0 end-1] $ufnnd]
      }
    }
  } else {
    set rv [file join {*}$sds $ufn]
  }
  if {$::iun ne ""} { puts $::iun "$ufn|$sfn|$rv" }
  return $rv
}

set owd [pwd]
cd $::doc_root
set inhtml [lmap f $argv {finorm $f}]

package require sqlite3

try {
  sqlite3 db :memory:
  db eval {
    CREATE TABLE IF NOT EXISTS LinkDefs(
     url TEXT, frag TEXT,
     UNIQUE(url, frag) ON CONFLICT IGNORE
    );
    CREATE TABLE IF NOT EXISTS IntLinkRefs(
     url TEXT, frag TEXT, fsrc TEXT,
     UNIQUE(url, frag, fsrc) ON CONFLICT IGNORE
    );
    CREATE TABLE IF NOT EXISTS ExtLinkRefs(
     url TEXT, frag TEXT, fsrc TEXT,
     UNIQUE(url, frag, fsrc) ON CONFLICT IGNORE
    );
    CREATE VIEW IF NOT EXISTS BrokenPageLinks AS
    SELECT r.url || iif(r.frag <> '', '#'||r.frag, '') AS url, r.fsrc as fsrc
    FROM IntLinkRefs r LEFT JOIN LinkDefs d USING(url)
    WHERE d.url IS NULL;
    CREATE VIEW IF NOT EXISTS BrokenFragLinks AS
    SELECT r.url || iif(r.frag <> '', '#'||r.frag, '') AS url, r.fsrc as fsrc
    FROM IntLinkRefs r LEFT JOIN LinkDefs d USING(url,frag)
    WHERE d.url IS NULL;
    CREATE VIEW IF NOT EXISTS ExtHttpLinks AS
    SELECT DISTINCT url FROM ExtLinkRefs WHERE url LIKE 'http%'
    AND url NOT LIKE 'https://www.sqlite.org/src/%'
    AND url NOT LIKE 'https://sqlite.org/src/%'
    AND url NOT LIKE 'http://www.sqlite.org/src/%'
    AND url NOT LIKE 'http://sqlite.org/src/%'
    AND url NOT LIKE 'https://www.fossil-scm.org/fossil/artifact/%'
    AND url NOT LIKE 'https://sqlite.org/forum/forumpost/%'
    ;
  }
} on error sle {
  puts stderr "Error with DB: $sle"
  exit 1
}

proc add_ref {u f s} {
  try {
    set u [iunorm $u $s]
    db eval {
      INSERT INTO IntLinkRefs(url, frag, fsrc)
      VALUES($u, $f, $s)
    }
  } on error db_conflict {
  }
}

proc add_ext {u f s} {
  try {
    db eval {
      INSERT INTO ExtLinkRefs(url, frag, fsrc)
      VALUES($u, $f, $s)
    }
  } on error db_conflict {
  }
}

proc add_def {u f s} {
  try {
    set u [iunorm $u $s]
    db eval {
      INSERT INTO LinkDefs(url, frag)
      VALUES($u, $f)
    }
  } on error db_conflict {
  }
}

if {[info command parsehtml] ne "parsehtml"} {
  try {
    load [file join $owd search parsehtml.so]
  } on error erc {
    puts stderr "Error: Could not load parsehtml DLL ($erc)"
    exit 1
  }
}

db eval {BEGIN TRANSACTION}
puts -nonewline "\
Scanning [llength $inhtml] files for hyperlink defs and refs, working on #"
set nscanning 0
set nsay ""

set ext_url_re {^((?:https?://)|(?:ftp://)|(?:mailto:))([^#]+)(#.*)?}

foreach html_src $inhtml {
  set html_dir [file dirname $html_src]
  try {
    set rpfid [open $html_src r]
    set nbu [string length $nsay]
    set nsay [format "%d" [incr nscanning]]
    puts -nonewline "[string repeat \b $nbu]$nsay"
    flush stdout
  } on error erc {
    puts stderr "Error: $erc"
    exit 1
  }
  set doc [hdom parse [read $rpfid]]
  close $rpfid

  set src_basename [file tail $html_src]
  add_def $src_basename "" $html_src

  set rn [$doc root]

  $rn foreach_descendent dnode {
    set tag [$dnode tag]
    regsub {^h[1-9]$} $tag h? tag
    switch $tag {
      a {
        foreach {an av} [$dnode attr] {
          if {$an eq "name"} {
            add_def $src_basename $av $html_src
            continue
          } elseif {$an ne "href"} continue
          if {[regexp $ext_url_re $av _ transport loc at]} {
            add_ext "${transport}${loc}" $at $html_src
          } else {
            if {[regexp {^javascript:} $av]} continue
            if {![regexp {^([^#]*)#(.*)$} $av _ av at]} {
              set at ""
            } elseif {$av eq ""} {
              set av $html_src
            }
            add_ref $av $at $html_src
          }
        }
      }
      h? {
        foreach {an av} [$dnode attr] {
          if {$an eq "id"} {
            add_def $src_basename $av $html_src
            break
          }
        }
      }
    }
  }
  $doc destroy
}
db eval {COMMIT TRANSACTION}

cd $owd
puts "\nWriting $hlink_db"
file delete -force $hlink_db
db eval { VACUUM INTO $hlink_db }

db close
if {$::iun ne ""} { close $::iun }

	@echo 'make all;        # Do all of the above'
	@echo 'make spell;      # Spell check generated docs'
	@echo 'make fast;       # Build documentation only - no requirements'
	@echo 'make faster;     # Like fast, except build is incremental'
	@echo 'make schema;     # Run once to initialize the build process'
	@echo 'make private;    # Everything except searchdb'
	@echo 'make versions;   # Update SQLite release version list'
	@echo 'make linkcheck;  # Create hyperlink check DB, hlcheck.db'

all:	base evidence format_evidence matrix doc searchdb

private:	base evidence private_evidence matrix doc

fast:	base doc

sqlite3.h: $(BLD)/sqlite3.h
	cp $(BLD)/sqlite3.h orig-sqlite3.h
	sed 's/^SQLITE_API //' orig-sqlite3.h >sqlite3.h

# Generate the directory into which generated documentation files will
# be written.
#
docdir:
	mkdir -p doc doc/c3ref doc/matrix doc/matrix/c3ref doc/matrix/syntax

ifdef CHECKOUT_ONLY
CPIO_PASS_OPTS = --pass-through --make-directories --quiet --unconditional
PAGES_IN = $$(fossil ls $(DOC)/pages | sed -e '/\.in$$/! d ; s/^/.\//')
COPY_RAW_PAGES = cp --target-directory=doc $(fossil ls rawpages)
COPY_IMAGES = fossil ls images | cpio $(CPIO_PASS_OPTS) doc
else
PAGES_IN = $(DOC)/pages/*.in
COPY_RAW_PAGES = cp $(DOC)/rawpages/* doc
COPY_IMAGES = cp -r $(DOC)/images doc
endif

#
matrix:
	rm -rf doc/matrix/images
	cp -r doc/images doc/matrix
	cp $(DOC)/rawpages/sqlite.css doc/matrix
	./$(TCLSH) $(DOC)/matrix.tcl

URLCHK = ./urlcheck --ok-silent
linkcheck: urlcheck
	./$(TCLSH) hlinkchk.tcl doc hlcheck.db $$(find doc -name '*.html' -print)
	echo "Checking external URLs is expensive. To do so, enter this:"
	echo "echo 'SELECT * FROM ExtHttpLinks;'|sqlite3 hlcheck.db|$(URLCHK)"

#-------------------------------------------------------------------------

# Source files for the [tclsqlite3.search] executable.
#
SSRC = $(DOC)/search/searchc.c \
	    $(DOC)/search/parsehtml.c \

	mkdir -p doc/search.d/
	./$(TCLSH) $(DOC)/search/mkscript.tcl $(DOC)/search/admin.tcl.in >$@
	chmod 744 doc/search.d/admin

searchdb: $(TCLSH) doc/search doc/search.d/admin
	./$(TCLSH) $(DOC)/search/buildsearchdb.tcl

urlcheck: $(DOC)/urlcheck.c
	$(CC) -Os urlcheck.c -o $@ -lcurl

#	cp $(DOC)/search/search.tcl doc/search.d/admin
#	chmod +x doc/search.d/admin

fts5ext.so:	$(DOC)/search/fts5ext.c
	gcc -shared -fPIC -I. -DSQLITE_EXT \
		$(DOC)/search/fts5ext.c -o fts5ext.so

<title>Atomic Commit In SQLite</title>
<tcl>hd_keywords {atomic commit} {*Atomic Commit}</tcl>
<table_of_contents>

<h1> Introduction</h1>

<p>An important feature of transactional databases like SQLite
is "atomic commit".
Atomic commit means that either all database changes within a single
transaction occur or none of them occur.  With atomic commit, it
is as if many different writes to different sections of the database
file occur instantaneously and simultaneously.
Real hardware serializes writes to mass storage, and writing
a single sector takes a finite amount of time.
So it is impossible to truly write many different sectors of a
database file simultaneously and/or instantaneously.
But the atomic commit logic within
SQLite makes it appear as if the changes for a transaction
are all written instantaneously and simultaneously.</p>

<p>SQLite has the important property that transactions appear
to be atomic even if the transaction is interrupted by an
operating system crash or power failure.</p>

<p>This article describes the techniques used by SQLite to create the
illusion of atomic commit.</p>

<p>The information in this article applies only when SQLite is operating
in "rollback mode", or in other words when SQLite is not
using a [write-ahead log].  SQLite still supports atomic commit when
write-ahead logging is enabled, but it accomplishes atomic commit by
a different mechanism from the one described in this article.  See
the [WAL | write-ahead log documentation] for additional information on how
SQLite supports atomic commit in that context.</p>

<tcl>hd_fragment hardware</tcl>

the operating system.
For this reason, SQLite does a "flush" or "fsync" operation at key
points.  SQLite assumes that the flush or fsync will not return until
all pending write operations for the file that is being flushed have
completed.  We are told that the flush and fsync primitives
are broken on some versions of Windows and Linux.  This is unfortunate.
It opens SQLite up to the possibility of database corruption following
a power loss in the middle of a commit.  However, there is nothing
that SQLite can do to test for or remedy the situation.  SQLite
assumes that the operating system that it is running on works as
advertised.  If that is not quite the case, well then hopefully you
will not lose power too often.</p>

<p>SQLite assumes that when a file grows in length that the new
file space originally contains garbage and then later is filled in
with the data actually written.  In other words, SQLite assumes that
the file size is updated before the file content.  This is a
pessimistic assumption and SQLite has to do some extra work to make
sure that it does not cause database corruption if power is lost
between the time when the file size is increased and when the
new content is written.  The xDeviceCharacteristics method of
the [VFS] might indicate that the filesystem will always write the
data before updating the file size.  (This is the
SQLITE_IOCAP_SAFE_APPEND property for those readers who are looking
at the code.)  When the xDeviceCharacteristics method indicates
that files content is written before the file size is increased,
SQLite can forego some of its pedantic database protection steps
and thereby decrease the amount of disk I/O needed to perform a
commit.  The current implementation, however, makes no such assumptions
for the default VFSes for Windows and Unix.</p>

<p>SQLite assumes that a file deletion is atomic from the
point of view of a user process.  By this we mean that if SQLite
requests that a file be deleted and the power is lost during the
delete operation, once power is restored either the file will
exist completely with all if its original content unaltered, or
else the file will not be seen in the filesystem at all.  If
after power is restored the file is only partially deleted,
if some of its data has been altered or erased,
or the file has been truncated but not completely removed, then
database corruption will likely result.</p>

<p>SQLite assumes that the detection and/or correction of
bit errors caused by cosmic rays, thermal noise, quantum
fluctuations, device driver bugs, or other mechanisms, is the
responsibility of the underlying hardware and operating system.
SQLite does not add any redundancy to the database file for
the purpose of detecting corruption or I/O errors.
SQLite assumes that the data it reads is exactly the same data
that it previously wrote.</p>

<p>By default, SQLite assumes that an operating system call to write
a range of bytes will not damage or alter any bytes outside of that range
even if a power loss or OS crash occurs during that write.  We
call this the "[PSOW | powersafe overwrite]" property.
Prior to [version 3.7.9] ([dateof:3.7.9]),
SQLite did not assume powersafe overwrite.  But with the standard
sector size increasing from 512 to 4096 bytes on most disk drives, it
has become necessary to assume powersafe overwrite in order to maintain
historical performance levels and so powersafe overwrite is assumed by
default in recent versions of SQLite.  The assumption of powersafe
overwrite property can be disabled at compile-time or a run-time if
desired.  See the [PSOW | powersafe overwrite documentation] for further
details.


<a name="section_3_0"></a>
<h1> Single File Commit</h1>

the process that is using SQLite.  The database connection has
just been opened and no information has been read yet, so the
user space is empty.
</p>
<br clear="both">

<tcl>hd_fragment rdlck</tcl>
<a name="section_3_2"></a>
<h2> Acquiring A Read Lock</h2>

<img src="images/ac/commit-1.gif" align="right" hspace="15">

<p>Before SQLite can write to a database, it must first read
the database to see what is there already.  Even if it is just
appending new data, SQLite still has to read in the database

<br clear="both">
<a name="section_3_5"></a>
<h2> Creating A Rollback Journal File</h2>
<img src="images/ac/commit-4.gif" align="right" hspace="15">

<p>Prior to making any changes to the database file, SQLite first
creates a separate rollback journal file and writes into the
rollback journal the original
content of the database pages that are to be altered.
The idea behind the rollback journal is that it contains
all information needed to restore the database back to
its original state.</p>

<p>The rollback journal contains a small header (shown in green
in the diagram) that records the original size of the database
file.  So if a change causes the database file to grow, we
will still know the original size of the database.  The page
number is stored together with each database page that is
written into the rollback journal.</p>

<p>
  When a new file is created, most desktop operating systems
  (Windows, Linux, Mac OS X) will not actually write anything to
  disk.  The new file is created in the operating systems disk
  cache only.  The file is not created on mass storage until sometime

<br clear="both">
<a name="section_3_7"></a>
<h2> Flushing The Rollback Journal File To Mass Storage</h2>
<img src="images/ac/commit-6.gif" align="right" hspace="15">

<p>The next step is to flush the content of the rollback journal
file to nonvolatile storage.
As we will see later,
this is a critical step in insuring that the database can survive
an unexpected power loss.
This step also takes a lot of time, since writing to nonvolatile
storage is normally a slow operation.</p>

<p>This step is usually more complicated than simply flushing
the rollback journal to the disk.  On most platforms two separate
flush (or fsync()) operations are required.  The first flush writes
out the base rollback journal content.  Then the header of the
rollback journal is modified to show the number of pages in the
rollback journal.  Then the header is flushed to disk.  The details
on why we do this header modification and extra flush are provided
in a later section of this paper.</p>

<br clear="both">
<a name="section_3_8"></a>
<h2> Obtaining An Exclusive Lock</h2>

<h2>0 Flushing Changes To Mass Storage</h2>
<img src="images/ac/commit-9.gif" align="right" hspace="15">

<p>Another flush must occur to make sure that all the
database changes are written into nonvolatile storage.
This is a critical step to ensure that the database will
survive a power loss without damage.  However, because
of the inherent slowness of writing to disk or flash memory,
this step together with the rollback journal file flush in section
3.7 above takes up most of the time required to complete a
transaction commit in SQLite.</p>

<br clear="both">
<a name="section_3_11"></a>
<h2>1 Deleting The Rollback Journal</h2>

database file depending on whether or not the rollback
journal file exists.</p>

<p>Deleting a file is not really an atomic operation, but
it appears to be from the point of view of a user process.
A process is always able to ask the operating system "does
this file exist?" and the process will get back a yes or no
answer.  After a power failure that occurs during a
transaction commit, SQLite will ask the operating system
whether or not the rollback journal file exists.  If the
answer is "yes" then the transaction is incomplete and is
rolled back.  If the answer is "no" then it means the transaction
did commit.</p>

<p>The existence of a transaction depends on whether or
not the rollback journal file exists and the deletion
of a file appears to be an atomic operation from the point of
view of a user-space process.  Therefore,
a transaction appears to be an atomic operation.</p>

<p>The act of deleting a file is expensive on many systems.
As an optimization, SQLite can be configured to truncate
the journal file to zero bytes in length
or overwrite the journal file header with zeros.  In either
case, the resulting journal file is no longer capable of rolling

<br clear="both">
<a name="section_4_2"></a>
<h2> Hot Rollback Journals</h2>
<img src="images/ac/rollback-1.gif" align="right" hspace="15">

<p>The first time that any SQLite process attempts to access
the database file, it obtains a shared lock as described in
<a href="#section_3_2">section 3.2</a> above.
But then it notices that there is a
rollback journal file present.  SQLite then checks to see if
the rollback journal is a "hot journal".   A hot journal is
a rollback journal that needs to be played back in order to
restore the database to a sane state.  A hot journal only
exists when an earlier process was in the middle of committing
a transaction when it crashed or lost power.</p>

played back into the database file (and flushed to disk in case
we encounter yet another power failure), the hot rollback journal
can be deleted.</p>

<p>As in <a href="#section_3_11">section 3.11</a>, the journal
file might be truncated to zero length or its header might
be overwritten with zeros as an optimization on systems where
deleting a file is expensive.  Either way, the journal is no
longer hot after this step.</p>

<br clear="both">
<tcl>hd_fragment cont</tcl>
<h2> Continue As If The Uncompleted Writes Had Never Happened</h2>
<img src="images/ac/rollback-5.gif" align="right" hspace="15">

<p>The final recovery step is to reduce the exclusive lock back
to a shared lock.  Once this happens, the database is back in the
state that it would have been if the aborted transaction had never
started.  Since all of this recovery activity happens completely
automatically and transparently, it appears to the program using
SQLite as if the aborted transaction had never begun.</p>

<br clear="both">
<tcl>hd_fragment multicommit</tcl>
<h1> Multi-file Commit</h1>

<p>SQLite allows a single
<a href="c3ref/sqlite3.html">database connection</a> to talk to
two or more database files simultaneously through the use of
the <a href="lang_attach.html">ATTACH DATABASE</a> command.
When multiple database files are modified within a single
transaction, all files are updated atomically.
In other words, either all of the database files are updated or
else none of them are.
Achieving an atomic commit across multiple database files is
more complex that doing so for a single file.  This section
describes how SQLite works that bit of magic.</p>

<tcl>hd_fragment multijrnl</tcl>
<h2> Separate Rollback Journals For Each Database</h2>
<img src="images/ac/multi-0.gif" align="right" hspace="15">

<p>When multiple database files are involved in a transaction,
each database has its own rollback journal and each database
is locked separately.  The diagram at the right shows a scenario
where three different database files have been modified within
one transaction.  The situation at this step is analogous to
the single-file transaction scenario at
<a href="#section_3_6">step 3.6</a>.  Each database file has
a reserved lock.  For each database, the original content of pages
that are being changed have been written into the rollback journal
for that database, but the content of the journals have not yet
been flushed to disk.  No changes have been made to the database
file itself yet, though presumably there are changes being held
in user memory.</p>

<p>For brevity, the diagrams in this section are simplified from

<tcl>hd_fragment sprjrnl</tcl>
<h2> The Super-Journal File</h2>
<img src="images/ac/multi-1.gif" align="right" hspace="15">

<p>The next step in a multi-file commit is the creation of a
"super-journal" file.  The name of the super-journal file is
the same name as the original database filename (the database
that was opened using the
<a href="c3ref/open.html">sqlite3_open()</a> interface,
not one of the <a href="lang_attach.html">ATTACHed</a> auxiliary
databases) with the text "<b>-mj</b><i>HHHHHHHH</i>" appended where
<i>HHHHHHHH</i> is a random 32-bit hexadecimal number.  The
random <i>HHHHHHHH</i> suffix changes for every new super-journal.</p>

<p><i>(Nota bene: The formula for computing the super-journal filename

<br clear="both">
<tcl>hd_fragment multijrnlupdate</tcl>
<h2> Updating Rollback Journal Headers</h2>
<img src="images/ac/multi-2.gif" align="right" hspace="15">

<p>The next step is to record the full pathname of the super-journal file
in the header of every rollback journal.  Space to hold the
super-journal filename was reserved at the beginning of each rollback journal
as the rollback journals were created.</p>

<p>The content of each rollback journal is flushed to disk both before
and after the super-journal filename is written into the rollback
journal header.  It is important to do both of these flushes.  Fortunately,
the second flush is usually inexpensive since typically only a single
page of the journal file (the first page) has changed.</p>

<p>This step is analogous to
<a href="#section_3_7">step 3.7</a> in the single-file commit
scenario described above.</p>

<br clear="both">
<tcl>hd_fragment multidbupdate</tcl>
<h2> Updating The Database Files</h2>
<img src="images/ac/multi-3.gif" align="right" hspace="15">

<br clear="both">
<a name="section_5_5"></a>
<h2> Delete The Super-Journal File</h2>
<img src="images/ac/multi-4.gif" align="right" hspace="15">

<p>The next step is to delete the super-journal file.
This is the point where the multi-file transaction commits.
This step corresponds to
<a href="#section_3_11">step 3.11</a> in the single-file
commit scenario where the rollback journal is deleted.</p>

<p>If a power failure or operating system crash occurs at this
point, the transaction will not rollback when the system reboots
even though there are rollback journals present.  The
difference is the super-journal pathname in the header of the

<tcl>hd_fragment cleanup</tcl>
<h2> Clean Up The Rollback Journals</h2>
<img src="images/ac/multi-5.gif" align="right" hspace="15">

<p>The final step in a multi-file commit is to delete the
individual rollback journals and drop the exclusive locks on
the database files so that other processes can see the changes.
This corresponds to
<a href="#section_3_12">step 3.12</a> in the single-file
commit sequence.</p>

<p>The transaction has already committed at this point so timing
is not critical in the deletion of the rollback journals.
The current implementation deletes a single rollback journal
then unlocks the corresponding database file before proceeding

<tcl>hd_fragment completesectors</tcl>
<h2> Always Journal Complete Sectors</h2>

<p>When the original content of a database page is written into
the rollback journal (as shown in <a href="#section_3_5">section 3.5</a>),
SQLite always writes a complete sector of data, even if the
page size of the database is smaller than the sector size.
Historically, the sector size in SQLite has been hard coded to 512
bytes and since the minimum page size is also 512 bytes, this has never
been an issue.  But beginning with SQLite version 3.3.14, it is possible
for SQLite to use mass storage devices with a sector size larger than 512
bytes.  So, beginning with version 3.3.14, whenever any page within a
sector is written into the journal file, all pages in that same sector
are stored with it.</p>

PRAGMA synchronous=FULL;
</blockquote>

<p>The default synchronous setting is full so the above is what usually
happens.  However, if the synchronous setting is lowered to "normal",
SQLite only flushes the rollback journal once, after the page count has
been written.
This carries a risk of corruption because it might happen that the
modified (non-zero) page count reaches the disk surface before all
of the data does.  The data will have been written first, but SQLite
assumes that the underlying filesystem can reorder write requests and
that the page count can be burned into oxide first even though its
write request occurred last.  So as a second line of defense, SQLite
also uses a 32-bit checksum on every page of data in the rollback
journal.  This checksum is evaluated for each page during rollback
while rolling back a journal as described in
<a href="#section_4_4">section 4.4</a>.  If an incorrect checksum
is seen, the rollback is abandoned.  Note that the checksum does
not guarantee that the page data is correct since there is a small
but finite probability that the checksum might be right even if the data is
corrupt.  But the checksum does at least make such an error unlikely.
</p>

<li><p>No other processes can change the database so there is never
a need to check the change counter and clear the user-space cache
at the beginning of a transaction.</p></li>

<li><p>Each transaction can be committed by overwriting the rollback
journal header with zeros rather than deleting the journal file.
This avoids having to modify the directory entry for the journal file
and it avoids having to deallocate disk sectors associated with the
journal.  Furthermore, the next transaction will overwrite existing
journal file content rather than append new content and on most systems
overwriting is much faster than appending.</p></li>
</ol>

<p>The third optimization, zeroing the journal file header rather than
deleting the rollback journal file,

other end of the sector.  If a power loss occurs in the middle of
a linear write then part of the sector might be modified while the
other end is unchanged.  In an atomic sector write, either the entire
sector is overwritten or else nothing in the sector is changed.</p>

<p>We believe that most modern disk drives implement atomic sector
writes.  When power is lost, the drive uses energy stored in capacitors
and/or the angular momentum of the disk platter to provide power to
complete any operation in progress.  Nevertheless, there are so many
layers in between the write system call and the on-board disk drive
electronics that we take the safe approach in both Unix and w32 VFS
implementations and assume that sector writes are not atomic.  On the
other hand, device
manufacturers with more control over their filesystems might want
to consider enabling the atomic write property of xDeviceCharacteristics

<p>Deleting a file is an expensive operation on many systems.
So as an optimization, SQLite can be configured to avoid the
delete operation of <a href="#section_3_11">section 3.11</a>.
Instead of deleting the journal file in order to commit a transaction,
the file is either truncated to zero bytes in length or its
header is overwritten with zeros.  Truncating the file to zero
length saves having to make modifications to the directory containing
the file since the file is not removed from the directory.
Overwriting the header has the additional savings of not having
to update the length of the file (in the "inode" on many systems)
and not having to deal with newly freed disk sectors.  Furthermore,
at the next transaction the journal will be created by overwriting
existing content rather than appending new content onto the end
of a file, and overwriting is often much faster than appending.</p>

<p>SQLite can be configured to commit transactions by overwriting
the journal header with zeros instead of deleting the journal file
by setting the "PERSIST" journaling mode using the
<a href="pragma.html#pragma_journal_mode">journal_mode</a> PRAGMA.
For example:</p>

<blockquote><pre>
PRAGMA journal_mode=PERSIST;
</per></blockquote>

<p>The use of persistent journal mode provides a noticeable performance
improvement on many systems.  Of course, the drawback is that the
journal files remain on the disk, using disk space and cluttering
directories, long after the transaction commits.  The only safe way
to delete a persistent journal file is to commit a transaction
with journaling mode set to DELETE:</p>

<blockquote><pre>
PRAGMA journal_mode=DELETE;
BEGIN EXCLUSIVE;
COMMIT;
</per></blockquote>

<p>Beware of deleting persistent journal files by any other means
since the journal file might be hot, in which case deleting it will
corrupt the corresponding database file.</p>

<p>Beginning in SQLite [version 3.6.4] ([dateof:3.6.4]),
the TRUNCATE journal mode is
also supported:</p>

<blockquote><pre>
PRAGMA journal_mode=TRUNCATE;
</pre></blockquote>

power loss occurs and the properties of the damage inflicted.
Each test then reopens the database after the simulated crash and
verifies that the transaction either occurred completely
or not at all and that the database is in a completely
consistent state.</p>

<p>The crash tests in SQLite have discovered a number of very
subtle bugs (now fixed) in the recovery mechanism.  Some of
these bugs were very obscure and unlikely to have been found
using only code inspection and analysis techniques.  From this
experience, the developers of SQLite feel confident that any other
database system that does not use a similar crash test system
likely contains undetected bugs that will lead to database
corruption following a system crash or power failure.</p>

goes wrong and two or more processes are able to write the same
database file at the same time, severe damage can result.</p>

<p>We have received reports of implementations of both
Windows network filesystems and NFS in which locking was
subtly broken.  We can not verify these reports, but as
locking is difficult to get right on a network filesystem
we have no reason to doubt them.  You are advised to
avoid using SQLite on a network filesystem in the first place,
since performance will be slow.  But if you must use a
network filesystem to store SQLite database files, consider
using a secondary locking mechanism to prevent simultaneous
writes to the same database even if the native filesystem
locking mechanism malfunctions.</p>

<p>The versions of SQLite that come preinstalled on Apple
Mac OS X computers contain a version of SQLite that has been

system call on w32 in order to sync the file system buffers onto disk
oxide as shown in <a href="#section_3_7">step 3.7</a> and
<a href="#section_3_10">step 3.10</a>.  Unfortunately, we have received
reports that neither of these interfaces works as advertised on many
systems.  We hear that FlushFileBuffers() can be completely disabled
using registry settings on some Windows versions.  Some historical
versions of Linux contain versions of fsync() which are no-ops on
some filesystems, we are told.  Even on systems where
FlushFileBuffers() and fsync() are said to be working, often
the IDE disk control lies and says that data has reached oxide
while it is still held only in the volatile control cache.</p>

<p>On the Mac, you can set this pragma:</p>

<blockquote>

on systems that do not work this way.</p>

<tcl>hd_fragment filegarbage</tcl>
<h2> Garbage Written Into Files</h2>

<p>SQLite database files are ordinary disk files that can be
opened and written by ordinary user processes.  A rogue process
can open an SQLite database and fill it with corrupt data.
Corrupt data might also be introduced into an SQLite database
by bugs in the operating system or disk controller; especially
bugs triggered by a power failure.  There is nothing SQLite can
do to defend against these kinds of problems.</p>

<tcl>hd_fragment mvhotjrnl</tcl>
<h2> Deleting Or Renaming A Hot Journal</h2>

<p>If a crash or power loss does occur and a hot journal is left on
the disk, it is essential that the original database file and the hot
journal remain on disk with their original names until the database
file is opened by another SQLite process and rolled back.
During recovery at <a href="#section_4_2">step 4.2</a> SQLite locates
the hot journal by looking for a file in the same directory as the
database being opened and whose name is derived from the name of the
file being opened.  If either the original database file or the
hot journal have been moved or renamed, then the hot journal will
not be seen and the database will not be rolled back.</p>

This same content is also available as a
<a href="../capi3ref.html">single large HTML file</a>.
</p>

<p>The SQLite interface elements can be grouped into three categories:</p>

<ol>
<li><p><a href="../c3ref/objlist.html"><b>List Of Objects.</b></a>
    This is a list of all abstract objects and datatypes used by the
    SQLite library.  There are couple dozen objects in total, but
    the two most important objects are:
    A database connection object [sqlite3], and the
    prepared statement object [sqlite3_stmt].</p></li>

<li><p><a href="../c3ref/constlist.html"><b>List Of Constants.</b></a>
    This is a list of numeric constants used by SQLite and represented by
    #defines in the sqlite3.h header file.  These constants
    are things such as numeric [result codes] from
    various interfaces (ex: [SQLITE_OK]) or flags passed
    into functions to control behavior
    (ex: [SQLITE_OPEN_READONLY]).</p></li>

<li><p><a href="../c3ref/funclist.html"><b>List Of Functions.</b></a>
    This is a list of all functions and methods operating on the
    <a href="../c3ref/objlist.html">objects</a> and using and/or
    returning <a href="../c3ref/constlist.html">constants</a>.  There
    are many functions, but most applications only use a handful.
    </p></li>
</ol>

<tcl>
hd_close_aux
hd_enable_main 1
</tcl>

<h1 align="center">
C-language Interface Specification for SQLite
</h1>

<p>This page is intended to be a precise and detailed specification.
For a tutorial introductions, see instead:
<ul>
<li>[quickstart | SQLite In 3 Minutes Or Less] and/or
<li>the [cintro | Introduction To The SQLite C/C++ Interface].
</ul>
This same content is also available split out into
<a href="../c3ref/intro.html">some smaller pages</a>.</p>

<hr>

<tcl>
# Find the preferred keyword for a page given a list of
# acceptable keywords.
#

# contains information about documentation for all C-API elements.  This
# database is used by third-party wrappers (ex: python) when building
# their own documentation, in order to provide links back to the
# canonical SQLite documentation.  Changing this table will break the
# build on those third-party systems.
#
if {$::scan_pass == 2} {
  sqlite3 dbtoc toc.db
  dbtoc eval {
 BEGIN;
 DROP TABLE IF EXISTS toc;
 CREATE TABLE toc(
  name TEXT,  -- Name of interface
  type TEXT,  -- 'object', 'constant', or 'function'
  status INT, -- 0=normal, 1=experimental, 2=deprecated

hd_enable_main 1
</tcl>
<h2>List Of Objects:</h2>
<tcl>
hd_list_of_links {} 280 [lsort -nocase $objlist]
hd_enable_main 0
hd_putsnl {<p>Other lists:
<a href="../c3ref/constlist.html">Constants</a> and
<a href="../c3ref/funclist.html">Functions</a> and
<a href="../rescode.html">Result Codes</a>.}
hd_close_aux
hd_enable_main 1
hd_putsnl {<hr>}

# Do a table of contents for constants
#

<p>Also available: [error codes|list of error codes]</p>
<tcl>
set clist [lsort -index 1 $clist]
#puts clist=[list $clist]
hd_list_of_links {} 400 $clist
hd_enable_main 0
hd_putsnl {<p>Other lists:
<a href="../c3ref/objlist.html">Objects</a> and
<a href="../c3ref/funclist.html">Functions</a> and
<a href="../rescode.html">Result Codes</a>.</p>}
hd_enable_main 1
hd_close_aux
hd_putsnl {<hr>}

# Do a table of contents for functions
#

hd_putsnl "<!-- number of functions: $funccnts(0) -->"
hd_putsnl "<!-- number of deprecated functions: $funccnts(2) -->"
hd_putsnl "<!-- number of experimental functions: $funccnts(1) -->"
set funclist [lsort -index 1 $funclist]
hd_list_of_links {} 315 $funclist
hd_enable_main 0
hd_putsnl {<p>Other lists:
<a href="../c3ref/constlist.html">Constants</a> and
<a href="../c3ref/objlist.html">Objects</a> and
<a href="../rescode.html">Result Codes</a></p>}
hd_enable_main 1
hd_close_aux
hd_putsnl {<hr>}
toc_close
# Convert a fragment text label into a fragment name
#

  }
  hd_resolve $body
  show_methods_of_object c:$kw Constructor
  show_methods_of_object d:$kw Destructor
  show_methods_of_object m:$kw Method
  hd_enable_main 0
  hd_puts {<p>See also lists of
  <a href="../c3ref/objlist.html">Objects</a>,
  <a href="../c3ref/constlist.html">Constants</a>, and
  <a href="../c3ref/funclist.html">Functions</a>.</p>}
  hd_enable_main 1
  hd_close_aux
  hd_puts "<hr>"
}
</tcl>

  set aChng($nChng) [list $date $desc $options]
  set xrefChng($date) $nChng
  if {[regexp {\(([0-9.]+)\)} $date all vers]} {
    set xrefChng($vers) $nChng
  }
  incr nChng
}

chng {2023-02-15 (3.41.0)} {
<li>Query planner improvements:
    <ol type="a">
    <li> Make use of indexed expresssion within an aggregate query that
         includes a GROUP BY clause.
    <li> The query planner has improved awareness of when an index is covering,
         and adjusts predicted runtimes accordingly.
    <li> The query planner is more aggressive about using co-routines rather
         than materializing subqueries and views.
    </ol>
<li>Add the base64 and base85 application-defined functions as an extension and
    include that extension in the [CLI].
<li>Add the [sqlite3_stmt_scanstatus_v2()] interface. (This interface is only
    available if SQLite is compiled using [SQLITE_ENABLE_STMT_SCANSTATUS].)
<li>In-memory databases created using [sqlite3_deserialize()] now report their
    filename as an empty string, not as 'x'.
<li>The new makefile target "sqlite3r.c" builds an [amalgamation] that includes
    the [recovery extension].
<li>Changes to the [CLI]:
    <ol type="a">
    <li> Add the new base64() and base85() SQL functions
    <li> Enhanced [EXPLAIN QUERY PLAN] output using the new [sqlite3_stmt_scanstatus_v2()]
         interface when compiled using [SQLITE_ENABLE_STMT_SCANSTATUS].
    <li> The "<tt>.scanstats est</tt>" command provides query planner estimates in profiles.
    <li> The continuation prompt indicates if the input is currently inside of a
         string literal, identifier literal, comment, trigger definition, etc.
    <li> Enhance the --safe command-line option to disallow dangerous SQL functions.
    </ol>
<li>Miscellaneous performance enhancements.
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: <i>pending</i>
<li>SHA3-256 for sqlite3.c: <i>pending</i>
}

chng {2022-11-16 (3.40.0)} {
<li> Add support for compiling [https://sqlite.org/wasm|SQLite to WASM]
     and running it in web browsers.  NB:  The WASM build and its interfaces
     are considered "beta" and are subject to minor changes if the need
     arises.  We anticipate finalizing the interface for the next release.
<li> Add the [recovery extension] that might be able to recover some content

<li>SQLITE_SOURCE_ID: 2022-02-22 18:58:40 40fa792d359f84c3b9e9d6623743e1a59826274e221df1bde8f47086968a1bab

<li>SHA3-256 for sqlite3.c: a69af0a88d59271a2dd3c846a3e93cbd29e7c499864f6c0462a3b4160bee1762
}

chng {2022-01-06 (3.37.2)} {
<li> Fix [https://sqlite.org/forum/forumpost/b03d86f9516cb3a2|a bug] introduced
     in [version 3.35.0] ([dateof:3.35.0]) that
     [SAVEPOINT bug|can cause database corruption]
     if a [SAVEPOINT] is rolled back while in [PRAGMA temp_store=MEMORY] mode,
     and other changes are made, and then the outer transaction commits.
     [https://sqlite.org/src/info/73c2b50211d3ae26|Check-in 73c2b50211d3ae26]
<li> Fix a long-standing problem with ON DELETE CASCADE and ON UPDATE CASCADE
     in which a cache of the [bytecode] used to implement the cascading change
     was not being reset following a local DDL change.

          beyond the single database file named on the command-line.
     <li> Performance improvements when reading SQL statements
          that span many lines.
     </ol>
<li> Added the [sqlite3_autovacuum_pages()] interface.
<li> The [sqlite3_deserialize()] does not and has never worked for the TEMP
     database.  That limitation is now noted in the documentation.
<li> The query planner now omits ORDER BY clauses on subqueries and views
     if removing those clauses does not change the semantics of the query.
<li> The [generate_series] table-valued function extension is modified so that
     the first parameter ("START") is now required.  This is done as a way to
     demonstrate how to write table-valued functions with required parameters.
     The legacy behavior is available using the -DZERO_ARGUMENT_GENERATE_SERIES
     compile-time option.
<li> Added new [sqlite3_changes64()] and [sqlite3_total_changes64()] interfaces.

     query result.
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2021-04-19 18:32:05 1b256d97b553a9611efca188a3d995a2fff712759044ba480f9a0c9e98fae886
<li>SHA3-256 for sqlite3.c: e42291343e8f03940e57fffcf1631e7921013b94419c2f943e816d3edf4e1bbe
} {patchagainst 3.35.0 patchagainst 3.35.1 patchagainst 3.35.2 patchagainst 3.35.3 patchagainst 3.35.4}

chng {2021-04-02 (3.35.4)} {
<li> Fix a defect in the query planner optimization identified by
     item 8b above.  Ticket
     [https://sqlite.org/src/info/de7db14784a08053|de7db14784a08053].
<li> Fix a defect in the new [RETURNING] syntax.  Ticket
     [https://sqlite.org/src/info/132994c8b1063bfb|132994c8b1063bfb].
<li> Fix the new [RETURNING] feature so that it raises an error if one of
     the terms in the RETURNING clause references a unknown table, instead
     of silently ignoring that error.

<li> Fix the [.mode|"box" output mode] in the [CLI] so that it works with statements that
     returns one or more rows of zero columns (such as [PRAGMA incremental_vacuum]).
     [https://sqlite.org/forum/forumpost/afbbcb5b72|Forum post afbbcb5b72].
<li> Improvements to error messages generated by faulty common table expressions.
     [https://sqlite.org/forum/forumpost/aa5a0431c99e631|Forum post aa5a0431c99e].
<li> Fix some incorrect assert() statements.
<li> Fix to the [select-stmt|SELECT statement syntax diagram] so that the FROM clause
     syntax is shown correctly.
     [https://sqlite.org/forum/forumpost/9ed02582fe|Forum post 9ed02582fe].
<li> Fix the EBCDIC character classifier so that it understands newlines as whitespace.
     [https://sqlite.org/forum/forumpost/58540ce22dcd5fdcd|Forum post 58540ce22dcd].
<li> Improvements the [xBestIndex] method in the implementation of the
     (unsupported) [https://sqlite.org/src/file/ext/misc/wholenumber.c|wholenumber virtual table]
     extension so that it does a better job of convincing the query planner to
     avoid trying to materialize a table with an infinite number of rows.
     [https://sqlite.org/forum/forumpost/b52a020ce4|Forum post b52a020ce4].
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2021-03-26 12:12:52 4c5e6c200adc8afe0814936c67a971efc516d1bd739cb620235592f18f40be2a
<li>SHA3-256 for sqlite3.c: 91ca6c0a30ebfdba4420bb35f4fd9149d13e45fc853d86ad7527db363e282683
} {patchagainst 3.35.0 patchagainst 3.35.1 patchagainst 3.35.2}

chng {2021-03-17 (3.35.2)} {
<li> Fix a problem in the
     [https://www.sqlite.org/src/file/ext/misc/appendvfs.c | appendvfs.c]
     extension that was introduced into version 3.35.0.
<li> Ensure that date/time functions with no arguments (which generate
     responses that depend on the current time) are treated as
     [non-deterministic functions]. Ticket
     [https://sqlite.org/src/info/2c6c8689fb5f3d2f | 2c6c8689fb5f3d2f]
<li> Fix a problem in the [sqldiff] utility program having to do with
     unusual whitespace characters in a [virtual table] definition.

<li> The [SQLITE_DBCONFIG_ENABLE_TRIGGER] and [SQLITE_DBCONFIG_ENABLE_VIEW]
     settings are modified so that they only control triggers and views
     in the main database schema or in attached database schemas and not in
     the TEMP schema. TEMP triggers and views are always allowed.
<li> Query planner/optimizer improvements:
     <ol type="a">
     <li> Enhancements to the [min/max optimization] so that it works better
          with the IN operator and the OP_SeekScan optimization of the
          previous release.
     <li> Attempt to process EXISTS operators in the WHERE clause as if
          they were IN operators, in cases where this is a valid transformation
          and seems likely to improve performance.
     <li> Allow UNION ALL sub-queries to be [flattened] even if the parent query is a join.
     <li> Use an index, if appropriate, on IS NOT NULL expressions in the WHERE clause,
          even if STAT4 is disabled.

          [.mode|.mode tabs].
     <li> The --init option reports an error if the file named as its argument
          cannot be opened.  The --init option also now honors the --bail option.
     </ol>
<li> Query planner improvements:
     <ol type="a">
     <li> Improved estimates for the cost of running a DISTINCT operator.
     <li> When doing an UPDATE or DELETE using a multi-column index where
          only a few of the earlier columns of the index are useful for the
          index lookup, postpone doing the main table seek until after all
          WHERE clause constraints have been evaluated, in case those
          constraints can be covered by unused later terms of the index,
          thus avoiding unnecessary main table seeks.
     <li> The new OP_SeekScan opcode is used to improve performance of
          multi-column index look-ups when later columns are constrained
          by an IN operator.
     </ol>
<li> The [BEGIN IMMEDIATE] and [BEGIN EXCLUSIVE] commands now work even

<li>SQLITE_SOURCE_ID: 2020-05-22 17:46:16 5998789c9c744bce92e4cff7636bba800a75574243d6977e1fc8281e360f8d5a
<li>SHA3-256 for sqlite3.c: 33ed868b21b62ce1d0352ed88bdbd9880a42f29046497a222df6459fc32a356f
}

chng {2020-01-27 (3.31.1)} {
<li> Revert the data layout for an internal-use-only SQLite data structure.
     Applications that use SQLite should never reference internal SQLite
     data structures, but some do anyhow, and a change to one such
     data structure in 3.30.0 broke a popular and widely-deployed
     application.  Reverting that change in SQLite, at least temporarily,
     gives developers of misbehaving applications time to fix their code.
<li> Fix a typos in the sqlite3ext.h header file that prevented the
     [sqlite3_stmt_isexplain()] and [sqlite3_value_frombind()] interfaces
     from being called from [loadable extensions|run-time loadable extensions].
<p><b>Hashes:</b>

<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2020-01-22 18:38:59 f6affdd41608946fcfcea914ece149038a8b25a62bbe719ed2561c649b86d824
<li>SHA3-256 for sqlite3.c: a5fca0b9f8cbf80ac89b97193378c719d4af4b7d647729d8df9c0c0fca7b1388
}

chng {2019-10-10 (3.30.1)} {
<li> Fix a bug in the [query flattener] that might cause a segfault
for nested queries that use the new
[FILTER clause on aggregate functions].
Ticket [https://www.sqlite.org/src/info/1079ad19993d13fa|1079ad19993d13fa]
<li> Cherrypick fixes for other obscure problems found since the 3.30.0
     release
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2019-10-10 20:19:45 18db032d058f1436ce3dea84081f4ee5a0f2259ad97301d43c426bc7f3df1b0b
<li>SHA3-256 for sqlite3.c: f96fafe4c110ed7d77fc70a7d690e5edd1e64fefb84b3b5969a722d885de1f2d

       creates new directories along the path of a new file, it gives them
       umask permissions rather than the same permissions as the file.
  <li> Change [--update option] in the [.archive command] so that it skips
       files that are already in the archive and are unchanged.  Add the
       new --insert option that works like --update used to work.
</ol>
<li> Added the [https://sqlite.org/src/file/ext/misc/fossildelta.c|fossildelta.c]
     extension that can create, apply, and deconstruct the
 [https://fossil-scm.org/fossil/doc/trunk/www/delta_format.wiki|Fossil DVCS file delta format]
     that is used by the [RBU extension].
<li> Added the [SQLITE_DBCONFIG_WRITABLE_SCHEMA] verb for the [sqlite3_db_config()]
     interface, that does the same work as [PRAGMA writable_schema] without using the
     SQL parser.
<li> Added the [sqlite3_value_frombind()] API for determining if the argument
     to an SQL function is from a [bound parameter].
<li> Security and compatibilities enhancements to [fts3_tokenizer()]:
<ol type="a">
  <li> The [fts3_tokenizer()] function always returns NULL
       unless either the legacy application-defined FTS3 tokenizers interface
       are enabled using
       the [sqlite3_db_config]([SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER])
       setting, or unless the first argument to fts3_tokenizer() is a [bound parameter].
  <li> The two-argument version of [fts3_tokenizer()] accepts a pointer to the
       tokenizer method object even without
       the [sqlite3_db_config]([SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER]) setting
       if the second argument is a [bound parameter]
</ol>
<li> Improved robustness against corrupt database files.
<li> Miscellaneous performance enhancements
<li> Established a Git mirror of the offical SQLite source tree.
     The canonical sources for SQLite are maintained using the
     [https://fossil-scm.org/|Fossil DVCS] at [https://sqlite.org/src].
     The Git mirror can be seen at [https://github.com/sqlite/sqlite].
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2019-04-16 19:49:53 884b4b7e502b4e991677b53971277adfaf0a04a284f8e483e2553d0f83156b50
<li>SHA3-256 for sqlite3.c: 411efca996b65448d9798eb203d6ebe9627b7161a646f5d00911e2902a57b2e9
}

chng {2019-02-25 (3.27.2)} {
<li> Fix a bug in the IN operator that was introduced by an
     attempted optimization in version 3.27.0. Ticket
     [https://www.sqlite.org/src/info/df46dfb631f75694|df46dfb631f75694]
<li> Fix a bug causing a crash when a [window function] is misused.  Ticket
     [https://www.sqlite.org/src/info/4feb3159c6bc3f7e33959|4feb3159c6bc3f7e33959].
<li> Fix various documentation typos
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: bd49a8271d650fa89e446b42e513b595a717b9212c91dd384aab871fc1d0f6d7

<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: 2019-02-08 13:17:39 0eca3dd3d38b31c92b49ca2d311128b74584714d9e7de895b1a6286ef959a1dd
<li>SHA3-256 for sqlite3.c: 11c14992660d5ac713ea8bea48dc5e6123f26bc8d3075fe5585d1a217d090233
} {patchagainst 1}

chng {2019-02-07 (3.27.0)} {
<li>Added the [VACUUM INTO] command
<li>Issue an SQLITE_WARNING message on the [error log] if a
[double-quoted string literal] is used.
<li>The [sqlite3_normalized_sql()] interface works on any prepared statement
created using [sqlite3_prepare_v2()] or [sqlite3_prepare_v3()].  It is no
longer necessary to use [sqlite3_prepare_v3()] with [SQLITE_PREPARE_NORMALIZE]
in order to use [sqlite3_normalized_sql()].
<li>Added the remove_diacritics=2 option to [FTS3] and [FTS5].
<li>Added the [SQLITE_PREPARE_NO_VTAB] option to [sqlite3_prepare_v3()].

       in the documentation, but was previously a no-op.
  <li> Enhance the "deserialize" command of the [TCL Interface] to give it
       new "--maxsize N" and "--readonly BOOLEAN" options.
</ol>
<li>Enhancements to the [CLI], mostly to support testing and debugging
of the SQLite library itself:
<ol type="a">
  <li> Add support for ".open --hexdb". The
       "[https://sqlite.org/src/doc/trunk/tool/dbtotxt.md|dbtotxt]" utility
       program used to generate the text for the "hexdb" is added to the
       source tree.
  <li> Add support for the "--maxsize N" option on ".open --deserialize".
  <li> Add the "--memtrace" command-line option, to show all memory allocations
       and deallocations.
  <li> Add the ".eqp trace" option on builds with SQLITE_DEBUG, to enable
       bytecode program listing with indentation and
       [PRAGMA vdbe_trace] all in one step.
  <li> Add the ".progress" command for accessing
       the [sqlite3_progress_handler()] interface.
  <li> Add the "--async" option to the ".backup" command.
  <li> Add options "--expanded", "--normalized", "--plain", "--profile", "--row",
       "--stmt", and "--close" to the ".trace" command.
</ol>
<li> Increased robustness against malicious SQL that is run against a
     maliciously corrupted database.
 <p><b>Bug fixes:</b>
<li>Do not use a partial index to do a table scan on an IN operator.
Ticket [https://www.sqlite.org/src/info/1d958d90596593a774|1d958d90596593a774].
<li>Fix the [query flattener] so that it works on queries that contain
subqueries that use [window functions].
Ticket [https://www.sqlite.org/src/info/f09fcd17810f65f717|709fcd17810f65f717]

[LEFT JOIN strength reduction optimization] in which the optimization
was being applied inappropriately due to an IS NOT NULL operator.
Ticket [https://www.sqlite.org/src/info/5948e09b8c415bc45d|5948e09b8c415bc45d].
<li>Fix the [REPLACE] command so that it is no longer able to sneak a
NULL value into a NOT NULL column even if the NOT NULL column has a default
value of NULL.
Ticket [https://www.sqlite.org/src/info/e6f1f2e34dceeb1ed6|e6f1f2e34dceeb1ed6]
<li>Fix a problem with the use of [window functions] used within
[correlated subqueries].
Ticket [https://www.sqlite.org/src/info/d0866b26f83e9c55e3|d0866b26f83e9c55e3]
<li>Fix the [ALTER TABLE RENAME COLUMN] command so that it works for tables
that have redundant UNIQUE constraints.
Ticket [https://www.sqlite.org/src/info/bc8d94f0fbd633fd9a|bc8d94f0fbd633fd9a]
<li>Fix a bug that caused [zeroblob] values to be truncated when inserted into
a table that uses an [expression index].

chng {2018-12-01 (3.26.0)} {
<li>Optimization: When doing an [UPDATE] on a table with [indexes on expressions],
    do not update the expression indexes if they do not refer to any of the columns
    of the table being updated.
<li>Allow the [xBestIndex()] method of [virtual table] implementations to return
    [SQLITE_CONSTRAINT] to indicate that the proposed query plan is unusable and
    should not be given further consideration.
<li>Added the [SQLITE_DBCONFIG_DEFENSIVE] option which disables the ability to
    create corrupt database files using ordinary SQL.
<li>Added support for read-only [shadow tables] when the [SQLITE_DBCONFIG_DEFENSIVE]
    option is enabled.
<li>Added the [PRAGMA legacy_alter_table] command, which if enabled causes the
    [ALTER TABLE] command to behave like older version of SQLite (prior to
    version 3.25.0) for compatibility.
<li>Added [PRAGMA table_xinfo] that works just like [PRAGMA table_info]

  <li>Added the [geopoly_ccw()] function.
</ol>
<li>Enhancements to the [session] extension:
<ol type="a">
  <li>Added the [SQLITE_CHANGESETAPPLY_INVERT] flag
  <li>Added the [sqlite3changeset_start_v2()] interface and the
      [SQLITE_CHANGESETSTART_INVERT] flag.
  <li>Added the
      [https://sqlite.org/src/file/ext/session/changesetfuzz.c|changesetfuzz.c]
      test-case generator utility.
</ol>
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2018-12-01 12:34:55 bf8c1b2b7a5960c282e543b9c293686dccff272512d08865f4600fb58238b4f9"
<li>SHA3-256 for sqlite3.c: 72c08830da9b5d1cb397c612c0e870d7f5eb41a323b41aa3d8aa5ae9ccedb2c4
}

chng {2018-09-18 (3.25.1)} {
<li> Extra sanity checking added to ALTER TABLE in the 3.25.0 release
     sometimes raises a false-positive
     when the table being modified has a trigger that
     updates a virtual table.  The false-positive caused the ALTER
     TABLE to rollback, thus leaving the schema unchanged.
     Ticket [https://sqlite.org/src/info/b41031ea2b537237|b41031ea2b537237].
<li> The fix in the 3.25.0 release for the endless-loop in the byte-code
     associated with the ORDER BY LIMIT optimization did not work for
     some queries involving window functions.  An additional correction
     is required.  Ticket
     [https://sqlite.org/src/info/510cde277783b5fb|510cde277783b5fb]
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2018-09-18 20:20:44 2ac9003de44da7dafa3fbb1915ac5725a9275c86bf2f3b7aa19321bf1460b386"
<li>SHA3-256 for sqlite3.c: 1b2302e7a54cc99c84ff699a299f61f069a28e1ed090b89e4430ca80ae2aab06

     Only available if compiled with SQLITE_ENABLE_SORTER_REFERENCES.
<li> Improve the format of the [EXPLAIN QUERY PLAN] raw output, so that
     it gives better information about the query plan and about the
     relationships between the various components of the plan.
<li> Added the [SQLITE_DBCONFIG_RESET_DATABASE] option to the
     [sqlite3_db_config()] API.
<p><b>[CLI] Enhancements:</b>
<li> Automatically intercepts the raw [EXPLAIN QUERY PLAN]
     output and reformats it into an ASCII-art graph.
<li> Lines that begin with "#" and that are not in the middle of an
     SQL statement are interpreted as comments.
<li> Added the --append option to the ".backup" command.
<li> Added the ".dbconfig" command.
<p><b>Performance:</b>
<li> [UPDATE] avoids unnecessary low-level disk writes when the contents
     of the database file do not actually change.
     For example, "UPDATE t1 SET x=25 WHERE y=?" generates no extra
     disk I/O if the value in column x is already 25.  Similarly,
     when doing [UPDATE] on records that span multiple pages, only
     the subset of pages that actually change are written to disk.
     This is a low-level performance optimization only and does not
     affect the behavior of TRIGGERs or other higher level SQL
     structures.
<li> Queries that use ORDER BY and LIMIT now try to avoid computing
     rows that cannot possibly come in under the LIMIT. This can greatly
     improve performance of ORDER BY LIMIT queries, especially when the
     LIMIT is small relative to the number of unrestricted output rows.
<li> The [OR optimization] is allowed to proceed
     even if the OR expression has also been converted into an IN
     expression.  Uses of the OR optimization are now also
     [eqp-or-opt|more clearly shown] in the [EXPLAIN QUERY PLAN] output.
<li> The query planner is more aggressive about using
     [automatic indexes] for views and subqueries for which it is
     not possible to create a persistent index.
<li> Make use of the one-pass UPDATE and DELETE query plans in the
     [R-Tree extension] where appropriate.
<li> Performance improvements in the LEMON-generated parser.

       maximum.
</ol>
<li> Bug fixes:
<ol type='a'>
  <li> Fix the parser to accept valid [row value] syntax.
       Ticket [https://www.sqlite.org/src/info/7310e2fb3d046a5|7310e2fb3d046a5]
  <li> Fix the query planner so that it takes into account dependencies in
       the arguments to table-valued functions in subexpressions in
       the WHERE clause.
       Ticket [https://www.sqlite.org/src/info/80177f0c226ff54|80177f0c226ff54]
  <li> Fix incorrect result with complex OR-connected WHERE and STAT4.
       Ticket [https://www.sqlite.org/src/info/ec32177c99ccac2|ec32177c99ccac2]
  <li> Fix potential corruption in [indexes on expressions] due to automatic
       datatype conversions.
       Ticket [https://www.sqlite.org/src/info/343634942dd54ab|343634942dd54ab]

<li>SQLITE_SOURCE_ID: "2018-04-02 11:04:16 736b53f57f70b23172c30880186dce7ad9baa3b74e3838cae5847cffb98f5cd2"
<li>SHA3-256 for sqlite3.c: 4bed3dc2dc905ff55e2c21fd2725551fc0ca50912a9c96c6af712a4289cb24fa
}

chng {2018-01-22 (3.22.0)} {
<li> The output of [sqlite3_trace_v2()] now shows each individual SQL statement
     run within a trigger.
<li> Add the ability to read from [WAL mode] databases even if the application
     lacks write permission on the database and its containing directory, as long as
     the -shm and -wal files exist in that directory.
<li> Added the [rtreecheck()] scalar SQL function to the [R-Tree extension].
<li> Added the [sqlite3_vtab_nochange()] and [sqlite3_value_nochange()] interfaces
     to help virtual table implementations optimize UPDATE operations.
<li> Added the [sqlite3_vtab_collation()] interface.
<li> Added support for the [FTS5 initial token|"&#94;" initial token syntax] in FTS5.
<li> New extensions:
<ol type='a'>
  <li> The [Zipfile virtual table] can read and write a
       [https://en.wikipedia.org/wiki/Zip_(file_format)|ZIP Archive].
  <li> Added the fsdir(PATH) [table-valued function] to the
       [https://sqlite.org/src/file/ext/misc/fileio.c|fileio.c] extension,
       for listing the files in a directory.
  <li> The [https://sqlite.org/src/file/ext/misc/btreeinfo.c|sqlite_btreeinfo]
       eponymous virtual table for introspecting and estimating the sizes of
       the btrees in a database.

       as a co-routine or using [query flattener|query flattening]
       now considers whether
       the result set of the outer query is "complex" (if it
       contains functions or expression subqueries).  A complex result
       set biases the decision toward the use of co-routines.
  <li> The planner avoids query plans that use indexes with unknown
       collating functions.
  <li> The planner omits unused LEFT JOINs even if they are not the
       right-most joins of a query.
</ol>
<li> Other performance optimizations:
<ol type='a'>
  <li> A smaller and faster implementation of text to floating-point
       conversion subroutine: sqlite3AtoF().
  <li> The [Lemon parser generator] creates a faster parser.

       [SQLite Archive] files using
       the [.archive command].
  <li> Added the experimental [.expert command]
  <li> Added the ".eqp trigger" variant of the ".eqp" command
  <li> Enhance the ".lint fkey-indexes" command so that it works with
       [WITHOUT ROWID] tables.
  <li> If the filename argument to the shell is a ZIP archive rather than
       an SQLite database, then the shell automatically opens that ZIP
       archive using the [Zipfile virtual table].
  <li> Added the [edit() SQL function].
  <li> Added the [export to excel|.excel command] to simplify exporting
       database content to a spreadsheet.
  <li> Databases are opened using
       [https://sqlite.org/src/file/ext/misc/appendvfs.c|Append VFS] when
       the --append flag is used on the command line or with the
       .open command.
</ol>
<li> Enhance the [SQLITE_ENABLE_UPDATE_DELETE_LIMIT] compile-time option so
     that it works for [WITHOUT ROWID] tables.
<li> Provide the [sqlite_offset(X)] SQL function that returns

<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2018-01-22 18:45:57 0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2171d"
<li>SHA3-256 for sqlite3.c: 206df47ebc49cd1710ac0dd716ce5de5854826536993f4feab7a49d136b85069

}

chng {2017-10-24 (3.21.0)} {
<li> Take advantage of the atomic-write capabilities in the
     [https://en.wikipedia.org/wiki/F2FS|F2FS filesystem] when available, for
     greatly reduced transaction overhead.  This currently requires the
     [SQLITE_ENABLE_BATCH_ATOMIC_WRITE] compile-time option.
<li> Allow [ATTACH] and [DETACH] commands to work inside of a transaction.
<li> Allow [WITHOUT ROWID virtual tables] to be writable if the PRIMARY KEY
     contains exactly one column.
<li> The "fsync()" that occurs after the header is written in a WAL reset

     input if the final new-line character is missing.
<li> Remove the rarely-used "scratch" memory allocator.  Replace it with the
     [SQLITE_CONFIG_SMALL_MALLOC] configuration setting that gives SQLite
     a hint that large memory allocations should be avoided when possible.
<li> Added the
     [https://sqlite.org/src/file/ext/misc/unionvtab.c|swarm virtual table]
     to the existing union virtual table extension.
<li> Added the
     [https://sqlite.org/src/file/src/dbpage.c|sqlite_dbpage virtual table]
     for providing direct access to pages
     of the database file.  The source code is built into the [amalgamation] and
     is activated using the [-DSQLITE_ENABLE_DBPAGE_VTAB] compile-time option.
<li> Add a new type of fts5vocab virtual table - "instance" - that provides
     direct access to an FTS5 full-text index at the lowest possible level.
<li> Remove a call to rand_s() in the Windows VFS since it was causing problems

} {patchagainst 1}


chng {2017-08-01 (3.20.0)} {
<li> Update the text of error messages returned by [sqlite3_errmsg()] for some
     error codes.
<li> Add new [pointer passing interfaces].
<li> Backwards-incompatible changes to some extensions in order to take
     advantage of the improved security offered by the new
     [pointer passing interfaces]:
     <ol type='a'>
     <li> [Extending FTS5] &rarr; requires [sqlite3_bind_pointer()] to find
          the fts5_api pointer.
     <li> [carray(PTR,N)] &rarr; requires [sqlite3_bind_pointer()] to set the PTR parameter.
     <li> [https://www.sqlite.org/src/file/ext/misc/remember.c|remember(V,PTR)]
          &rarr; requires [sqlite3_bind_pointer()] to set the PTR parameter.

  <li> Added the "--newlines" option to the "[.dump]" command to cause U+000a and
       U+000d characters to be output literally rather than escaped using the
       [replace()] function.
</ol>
<li> Query planner enhancements:
<ol type='a'>
  <li> When generating individual loops for each ORed term of an OR scan,
       move any constant WHERE expressions outside of the loop, as is
       done for top-level loops.
  <li> The query planner examines the values of bound parameters to help
       determine if a partial index is usable.
  <li> When deciding between two plans with the same estimated cost, bias
       the selection toward the one that does not use the sorter.
  <li> Evaluate WHERE clause constraints involving correlated subqueries
       last, in the hope that they never have be evaluated at all.
  <li> Do not use the [flattening optimization] for a sub-query on the RHS
       of a LEFT JOIN if that subquery reads data from a [virtual table] as
       doing so prevents the query planner from creating [automatic indexes]
       on the results of the sub-query, which can slow down the query.
</ol>
<li> Add [SQLITE_STMTSTATUS_REPREPARE], [SQLITE_STMTSTATUS_RUN],
     and [SQLITE_STMTSTATUS_MEMUSED] options for the
     [sqlite3_stmt_status()] interface.
<li> Provide [PRAGMA functions] for
     [PRAGMA integrity_check], [PRAGMA quick_check], and
     [PRAGMA foreign_key_check].
<li> Add the -withoutnulls option to the [TCL interface eval method].
<li> Enhance the [sqlite3_analyzer.exe] utility program so that it shows

<li> Fix the behavior of [sqlite3_column_name()] for queries that use the
     [flattening optimization] so that the result is consistent with other
     queries that do not use that optimization, and with PostgreSQL, MySQL,
     and SQLServer.  Ticket [https://sqlite.org/src/info/de3403bf5ae|de3403bf5ae].
<li> Fix the query planner so that it knows not to use [automatic indexes]
     on the right table of LEFT JOIN if the WHERE clause uses the [IS operator].
     Fix for [https://sqlite.org/src/info/ce68383bf6aba|ce68383bf6aba].
<li> Ensure that the query planner knows that any column of a
     [flattening optimization|flattened] LEFT JOIN can be NULL even
     if that column is labeled with "NOT NULL". Fix for ticket
     [https://sqlite.org/src/info/892fc34f173e99d8|892fc34f173e99d8].
<li> Fix rare false-positives in [PRAGMA integrity_check] when run on a database connection
     with [ATTACH|attached databases]. Ticket
     [https://sqlite.org/src/info/a4e06e75a9ab61a12|a4e06e75a9ab61a12]
<li> Fix a bug (discovered by OSSFuzz) that causes an assertion fault if certain
     dodgy CREATE TABLE declarations are used.  Ticket
     [https://sqlite.org/src/info/bc115541132dad136|bc115541132dad136]

chng {2017-03-30 (3.18.0)} {
<li>Added the [PRAGMA optimize] command
<li>The SQLite version identifier returned by the [sqlite_source_id()] SQL function
    and the [sqlite3_sourceid()] C API and found in the [SQLITE_SOURCE_ID] macro is
    now a 64-digit SHA3-256 hash instead of a 40-digit SHA1 hash.
<li>Added the [json_patch()] SQL function to the [json1|JSON1 extension].
<li>Enhance the [LIKE optimization] so that it works for arbitrary expressions on
    the left-hand side as long as the LIKE pattern on the right-hand side does not
    begin with a digit or minus sign.
<li>Added the [sqlite3_set_last_insert_rowid()] interface and use the new interface in
    the [FTS3], [FTS4], and [FTS5] extensions to ensure that the [sqlite3_last_insert_rowid()]
    interface always returns reasonable values.
<li>Enhance [PRAGMA integrity_check] and [PRAGMA quick_check] so that they verify
    [CHECK constraints].
<li>Enhance the query plans for joins to detect empty tables early and
    halt without doing unnecessary work.
<li>Enhance the [sqlite3_mprintf()] family of interfaces and the [printf SQL function]
    to put comma separators at the thousands marks for integers, if the "," format modifier
    is used in between the "%" and the "d" (example: "%,d").
<li>Added the -D[SQLITE_MAX_MEMORY]=<i>N</i> compile-time option.
<li>Added the [.sha3sum dot-command] and the [.selftest dot-command]
    to the [command-line shell]
<li>Begin enforcing [SQLITE_LIMIT_VDBE_OP]. This can be used, for example, to prevent
    excessively large prepared statements in systems that accept SQL queries from
    untrusted users.
<li>Various performance improvements.
<p><b>Bug Fixes:</b>
<li>Ensure that indexed expressions with collating sequences are handled correctly.

         for byteswapping when available.
    <li> Uses the [sqlite3_blob] key/value access object instead of SQL
         for pulling content out of R-Tree nodes
    <li> Other miscellaneous enhancements such as loop unrolling.
    </ol>
<li>Add the [SQLITE_DEFAULT_LOOKASIDE] compile-time option.
<li>Increase the default [lookaside memory allocator|lookaside]
    size from 512,125 to 1200,100
    as this provides better performance while only adding 56KB
    of extra memory per connection.  Memory-sensitive
    applications can restore the old
    default at compile-time, start-time, or run-time.
<li>Use compiler built-ins __builtin_sub_overflow(), __builtin_add_overflow(),
    and __builtin_mul_overflow() when available.  (All compiler
    built-ins can be omitted with the [SQLITE_DISABLE_INTRINSIC] compile-time
    option.)
<li>Added the [SQLITE_ENABLE_NULL_TRIM] compile-time option, which

<li>Fixed performance problems and potential stack overflows
    when creating [views] from multi-row VALUES clauses with
    hundreds of thousands of rows.
<li>Added the [https://www.sqlite.org/src/file/ext/misc/sha1.c|sha1.c]
    extension.
<li>In the [command-line shell], enhance the ".mode" command so that it
    restores the default column and row separators for modes "line",
    "list", "column", and "tcl".
<li>Enhance the [SQLITE_DIRECT_OVERFLOW_READ] option so that it works
    in [WAL mode] as long as the pages being read are not in the WAL file.
<li>Enhance the
    [Lemon parser generator]
    so that it can store the parser object as a stack variable rather than
    allocating space from the heap and make use of that enhancement in
    the [amalgamation].
<li>Other performance improvements. Uses about [CPU cycles used|6.5% fewer CPU cycles].
<p><b>Bug Fixes:</b>
<li>Throw an error if the ON clause of a LEFT JOIN references tables
    to the right of the ON clause.  This is the same behavior as
    PostgreSQL.  Formerly, SQLite silently converted the LEFT JOIN

<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2017-02-13 16:02:40 ada05cfa86ad7f5645450ac7a2a21c9aa6e57d2c"
<li>SHA1 for sqlite3.c: cc7d708bb073c44102a59ed63ce6142da1f174d1

}

chng {2017-01-06 (3.16.2)} {
<li>Fix the [REPLACE] statement for
    [WITHOUT ROWID] tables that lack secondary indexes so that
    it works correctly with triggers and foreign keys.  This was a new bug
    caused by performance optimizations added in version 3.16.0.
    Ticket [https://www.sqlite.org/src/info/30027b613b4|30027b613b4]
<li>Fix the [sqlite3_value_text()] interface so that it correctly
    translates content generated by [zeroblob()] into a string of all
    0x00 characters.  This is a long-standing issue discovered after the

    details on how this performance increase was computed.)
<li>Added experimental support for [PRAGMA functions].
<li>Added the [SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE] option to [sqlite3_db_config()].
<li>Enhance the [date and time functions] so that the 'unixepoch' modifier works
    for the full span of supported dates.
<li>Changed the default configuration of the [lookaside memory allocator] from
    500 slots of 128 bytes each into 125 slots of 512 bytes each.
<li>Enhanced "WHERE x NOT NULL" [partial indexes] so that they are usable if
    the "x" column appears in a LIKE or GLOB operator.
<li>Enhanced [sqlite3_interrupt()] so that it interrupts [checkpoint] operations that
    are in process.
<li>Enhanced the [LIKE] and [GLOB] matching algorithm to be faster
    for cases when the pattern contains multiple wildcards.
<li>Added the [SQLITE_FCNTL_WIN32_GET_HANDLE] file control opcode.
<li>Added ".mode quote" to the [command-line shell].

<li>SQLITE_SOURCE_ID: "2017-01-02 11:57:58 04ac0b75b1716541b2b97704f4809cb7ef19cccf"
<li>SHA1 for sqlite3.c: e2920fb885569d14197c9b7958e6f1db573ee669
}

chng {2016-11-28 (3.15.2)} {
<li> Multiple bug fixes to the [row value] logic that was introduced in version 3.15.0.
<li> Fix a NULL pointer dereference in ATTACH/DETACH following a maliciously constructed
     syntax error.  Ticket
     [https://www.sqlite.org/src/info/2f1b168ab4d4844|2f1b168ab4d4844].
<li> Fix a crash that can occur following an out-of-memory condition
     in the built-in [instr()] function.
<li> In the [json1|JSON extension], fix the JSON validator so that it correctly rejects
     invalid backslash escapes within strings.
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2016-11-28 19:13:37 bbd85d235f7037c6a033a9690534391ffeacecc8"
<li>SHA1 for sqlite3.c: 06d77b42a3e70609f8d4bbb97caf53652f1082cb
} {patchagainst 2 patchagainst 1}

chng {2016-11-04 (3.15.1)} {
<li> Added [SQLITE_FCNTL_WIN32_GET_HANDLE] file control opcode.
<li> Fix the [VACUUM] command so that it spills excess content to disk rather
     than holding everything in memory, and possible causing an out-of-memory
     error for larger database files.  This fixes an issue introduced by
     version 3.15.0.
<li> Fix a case (present since 3.8.0 - [dateof:3.8.0])
     where OR-connected terms in the ON clause of a LEFT JOIN
     might cause incorrect results.  Ticket
     [https://www.sqlite.org/src/info/34a579141b2c5ac|34a579141b2c5ac].
<li> Fix a case where the use of [row values] in the ON clause of a LEFT JOIN
     might cause incorrect results.  Ticket
     [https://www.sqlite.org/src/info/fef4bb4bd9185ec8f|fef4bb4bd9185ec8f].
<p><b>Hashes:</b>

<li> Skip NULL entries on range queries in [indexes on expressions].
     Fix for ticket
     [https://www.sqlite.org/src/tktview/4baa46491212947|4baa46491212947].
<li> Ensure that the [AUTOINCREMENT] counters in the sqlite_sequence
     table are initialized doing "Xfer Optimization" on "INSERT ... SELECT"
     statements.  Fix for ticket
     [https://www.sqlite.org/src/info/7b3328086a5c116c|7b3328086a5c116c].
<li> Make sure the ORDER BY LIMIT optimization
     (from check-in [https://www.sqlite.org/src/info/559733b09e9630fa|559733b09e])
     works with IN operators on INTEGER PRIMARY KEYs.  Fix for ticket
     [https://www.sqlite.org/src/info/96c1454cbfd9509|96c1454c]
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2016-10-14 10:20:30 707875582fcba352b4906a595ad89198d84711d8"
<li>SHA1 for sqlite3.c: fba106f8f6493c66eeed08a2dfff0907de54ae76
}

chng {2016-09-12 (3.14.2)} {
<li> Improved support for using the STDCALL calling convention in winsqlite3.dll.
<li> Fix the [sqlite3_trace_v2()] interface so that it is disabled if either the
callback or the mask arguments are zero, in accordance with the documentation.
<li> Fix commenting errors and improve the comments generated on [EXPLAIN] listings
when the [-DSQLITE_ENABLE_EXPLAIN_COMMENTS] compile-time option is used.
<li> Fix the ".read" command in the [command-line shell] so that it understands
that its input is not interactive.
<li> Correct affinity computations for a SELECT on the RHS of an IN operator.
Fix for ticket [https://sqlite.org/src/info/199df4168c|199df4168c].
<li> The ORDER BY LIMIT optimization is not valid unless the inner-most IN operator
loop is actually used by the query plan. Fix for
ticket [https://sqlite.org/src/info/0c4df46116e90f92|0c4df46116e90f92].
<li> Fix an internal code generator problem that was causing some [DELETE] operations
to no-op.  Ticket [https://sqlite.org/src/info/ef360601|ef360601]
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2016-09-12 18:50:49 29dbef4b8585f753861a36d6dd102ca634197bd6"
<li>SHA1 for sqlite3.c: bcc4a1989db45e7f223191f2d0f66c1c28946383

    [https://www.ietf.org/rfc/rfc4180.txt|RFC 4180] formatted comma-separated
    value files.
<li>Added the [carray() table-valued function] extension.
<li>Enabled [persistent loadable extensions] using the new
    [SQLITE_OK_LOAD_PERMANENTLY] return code from the extension
    entry point.
<li>Added the [SQLITE_DBSTATUS_CACHE_USED_SHARED] option to [sqlite3_db_status()].
<li>Add the
    [https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/vfsstat.c|vfsstat.c]
    loadable extension - a VFS shim that measures I/O
    together with an [eponymous virtual table] that provides access to the measurements.
<li>Improved algorithm for running queries with both an ORDER BY and a LIMIT where
    only the inner-most loop naturally generates rows in the correct order.
<li>Enhancements to [Lemon parser generator], so that it generates a
    faster parser.
<li>The [PRAGMA compile_options] command now attempts to show the version number
    of the compiler that generated the library.
<li>Enhance [PRAGMA table_info] so that it provides information about
    [eponymous virtual tables].
<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].

<li>Added the ".auth ON|OFF" command to the [command-line shell].
<li>Added the "--indent" option to the ".schema" and ".fullschema" commands of
    the [command-line shell], to turn on pretty-printing.
<li>Added the ".eqp full" option to the [command-line shell], that does both [EXPLAIN]
    and [EXPLAIN QUERY PLAN] on each statement that is evaluated.
<li>Improved unicode filename handling in the [command-line shell] on Windows.
<li>Improved resistance against goofy query planner decisions caused by
    incomplete or incorrect modifications to the [sqlite_stat1]
    table by the application.
<li>Added the [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION]) interface
    which allows the [sqlite3_load_extension()] C-API to be enabled while keeping the
    [load_extension()] SQL function disabled for security.
<li>Change the [temporary directory search algorithm] on Unix to allow directories with
    write and execute permission, but without read permission, to serve as temporary
    directories.  Apply this same standard to the "." fallback directory.
<p><b>Bug Fixes:</b>
<li>Fix a problem with the multi-row one-pass DELETE optimization that was
    causing it to compute incorrect answers with a self-referential subquery in
    the WHERE clause.  Fix for ticket
    [https://www.sqlite.org/src/info/dc6ebeda9396087|dc6ebeda9396087]
<li>Fix a possible segfault with DELETE when table is a [rowid table] with an
    [INTEGER PRIMARY KEY] and the WHERE clause contains a OR and
    the table has one or more indexes that are able to trigger the OR optimization,
    but none of the indexes reference any table columns other than the INTEGER PRIMARY KEY.
    Ticket [https://www.sqlite.org/src/info/16c9801ceba49|16c9801ceba49].
<li>When checking for the WHERE-clause push-down optimization, verify that all terms
    of the compound inner SELECT are non-aggregate, not just the last term. Fix for ticket
    [https://www.sqlite.org/src/info/f7f8c97e97597|f7f8c97e97597].

<li>SHA1 for sqlite3.c: de5a5898ebd3a3477d4652db143746d008b24c83
} {patchagainst 3 patchagainst 1}

chng {2016-04-08 (3.12.1)} {
<li>Fix a boundary condition error introduced by version 3.12.0
    that can result in a crash during heavy [SAVEPOINT] usage.
    Ticket [https://www.sqlite.org/src/info/7f7f8026eda38|7f7f8026eda38].
<li>Fix [views] so that they inherit column datatypes from the
    table that they are defined against, when possible.
<li>Fix the query planner so that IS and IS NULL operators are able
    to drive an index on a LEFT OUTER JOIN.
<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2016-04-08 15:09:49 fe7d3b75fe1bde41511b323925af8ae1b910bc4d"
<li>SHA1 for sqlite3.c: ebb18593350779850e3e1a930eb84a70fca8c1d1
} {patchagainst 2}

chng {2016-04-01 (3.9.3)} {
<li>Backport a
    [https://www.sqlite.org/src/info/c648539b52ca28c0|simple query planner optimization]
    that allows the IS operator
    to drive an index on a LEFT OUTER JOIN.  No other changes from the
    [version 3.9.2] baseline.
} {patchagainst 3.9.0 patchagainst 3.9.1 patchagainst 3.9.2}

chng {2016-03-29 (3.12.0)} {
<p><b>Potentially Disruptive Change:</b>
<li>The [SQLITE_DEFAULT_PAGE_SIZE] is increased from 1024 to 4096.
    The [SQLITE_DEFAULT_CACHE_SIZE] is changed from 2000 to -2000 so
    the same amount of cache memory is used by default.
    See the application note on the
    [version 3.12.0 page size change] for further information.
<p><b>Performance enhancements:</b>
<li>Enhancements to the [Lemon parser generator]
    so that it creates a smaller and faster SQL parser.
<li>Only create [master journal] files if two or more attached databases are all

    even if the [xBestIndex] method does not set the
    sqlite3_index_constraint_usage.omit flag of the
    virtual table column to the left of the IN operator.
<li>The query planner now does a better job of optimizing [virtual table]
    accesses in a 3-way or higher join where constraints on the virtual
    table are split across two or more other tables of the join.
<li>More efficient handling of [application-defined SQL functions], especially
    in cases where the application defines hundreds or thousands of
    custom functions.
<li>The query planner considers the LIMIT clause when estimating the cost
    of ORDER BY.
<li>The configure script (on unix) automatically detects
    pread() and pwrite() and sets compile-time options to use those OS
    interfaces if they are available.
<li>Reduce the amount of memory needed to hold the schema.
<li>Other miscellaneous micro-optimizations for improved performance and reduced
    memory usage.
<p><b>New Features:</b>
<li>Added the [SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER] option to [sqlite3_db_config()]
    which allows the two-argument version of the [fts3_tokenizer()] SQL function to
    be enabled or disabled at run-time.
<li>Added the [https://www.sqlite.org/src/artifact/d7cc99350?ln=403-443|sqlite3rbu_bp_progress()]
    interface to the [RBU] extension.
<li>The [PRAGMA defer_foreign_keys=ON] statement now also disables
    [foreign key actions|RESTRICT actions] on foreign key.
<li>Added the [sqlite3_system_errno()] interface.
<li>Added the [SQLITE_DEFAULT_SYNCHRONOUS] and [SQLITE_DEFAULT_WAL_SYNCHRONOUS]
    compile-time options.  The [SQLITE_DEFAULT_SYNCHRONOUS] compile-time option
    replaces the [SQLITE_EXTRA_DURABLE] option, which is no longer supported.
<li>Enhanced the ".stats" command in the [command-line shell] to show more
    information about I/O performance obtained from /proc, when available.

    containing directory when a rollback journal is unlinked in DELETE mode,
    for better durability.  The [SQLITE_EXTRA_DURABLE] compile-time option enables
    [PRAGMA synchronous=EXTRA] by default.
<li>Enhanced the [query planner] so that it is able to use
    a [covering index] as part of the [OR optimization].
<li>Avoid recomputing [NOT NULL] and [CHECK constraints] on unchanged
    columns in [UPDATE] statement.
<li>Many micro-optimizations, resulting in a library that is
    faster than the previous release.
<p><b>Enhancements to the [command-line shell]:</b>
<li>By default, the shell is now in "auto-explain" mode.  The output of
    [EXPLAIN] commands is automatically formatted.
<li>Added the ".vfslist" [dot-commands|dot-command].
<li>The [SQLITE_ENABLE_EXPLAIN_COMMENTS] compile-time option is now turned
    on by default in the standard builds.

<li>SHA1 for sqlite3.c: df01436c5fcfe72d1a95bc172158219796e1a90b

}

chng {2016-01-20 (3.10.2)} {
<p><b>Critical bug fix:</b>
<li>Version 3.10.0 introduced a case-folding bug in the [LIKE] operator which is fixed
    by this patch release.  Ticket
    [https://www.sqlite.org/src/info/80369eddd5c94 | 80369eddd5c94].
<p><b>Other miscellaneous bug fixes:</b>
<li>Fix a use-after-free that can occur when SQLite is compiled with -DSQLITE_HAS_CODEC.
<li>Fix the build so that it works with -DSQLITE_OMIT_WAL.
<li>Fix the configure script for the amalgamation so that the --readline option works again
    on Raspberry PIs.
<p><b>Hashes:</b>

<li>Added the --enable-editline and --enable-static-shell options
    to the various autoconf-generated configure scripts.
<li>Omit all use of "awk" in the makefiles, to make building easier for MSVC users.
<p><b>Important fixes:</b>
<li>Fix inconsistent integer to floating-point comparison operations that
    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-02 (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]
<li>Fix a query planner problem that could result in an incorrect
    answer due to the use of [automatic indexing] in subqueries in
    the FROM clause of a correlated scalar subqueries.  Fix for ticket
    [https://www.sqlite.org/src/info/8a2adec1|8a2adec1].

    initially created.  Missing tables and functions are reported when
    the VIEW is used in a query.
<li>Added the [sqlite3_value_subtype()] and [sqlite3_result_subtype()]
    interfaced (used by [the json1 extension]).
<li>The query planner is now able to use [partial indexes] that contain
    AND-connected terms in the WHERE clause.
<li>The sqlite3_analyzer.exe utility is updated to report the depth of
    each btree and to show the average fanout for indexes and
    WITHOUT ROWID tables.
<li>Enhanced the [dbstat virtual table] so that it can be used as a
    [table-valued function] where the argument is the schema to be
    analyzed.
<p><b>Other changes:</b>
<li>The [sqlite3_memory_alarm()] interface, which has been deprecated and
    undocumented for 8 years, is changed into a no-op.
<p><b>Important fixes:</b>
<li>Fixed a critical bug in the
    [https://www.sqlite.org/see/doc/trunk/www/readme.wiki|SQLite Encryption Extension] that
    could cause the database to become unreadable and unrecoverable if a [VACUUM] command
    changed the size of the encryption nonce.
<li>Added a memory barrier in the implementation of
    [sqlite3_initialize()] to help ensure that it is thread-safe.
<li>Fix the [OR optimization] so that it always ignores subplans that
    do not use an index.
<li>Do not apply the WHERE-clause pushdown optimization on terms that originate
    in the ON or USING clause of a LEFT JOIN.  Fix for ticket

    Windows [VFS].
<li>The [sqlite3_profile()] callback is invoked (by [sqlite3_reset()] or
    [sqlite3_finalize()]) for statements that did not run to completion.
<li>Enhance the page cache so that it can preallocate a block of memory to
    use for the initial set page cache lines.  Set the default preallocation
    to 100 pages.  Yields about a 5% performance increase on common workloads.
<li>Miscellaneous micro-optimizations result in 22.3% more work for the same
    number of CPU cycles relative to the previous release.
    SQLite now runs twice as fast as [version 3.8.0] and three times as
    fast as [version 3.3.9].
    (Measured using
    [http://valgrind.org/docs/manual/cg-manual.html|cachegrind] on the
    [http://www.sqlite.org/src/artifact/83f6b3318f7ee|speedtest1.c] workload on
    Ubuntu 14.04 x64 with gcc 4.8.2 and -Os. Your performance may vary.)
<li>Added the [sqlite3_result_zeroblob64()] and [sqlite3_bind_zeroblob64()]
    interfaces.
<p><b>Important bug fixes:</b>
<li>Fix [CREATE TABLE AS] so that columns of type TEXT never end up

<p><b>Hashes:</b>
<li>SQLITE_SOURCE_ID: "2015-07-27 13:49:41 b8e92227a469de677a66da62e4361f099c0b79d0"
<li>SHA1 for sqlite3.c: 719f6891abcd9c459b5460b191d731cd12a3643e
}

chng {2015-05-20 (3.8.10.2)} {
<li>Fix an index corruption issue introduced by [version 3.8.7].  An index
    with a TEXT key can be corrupted by an [INSERT] into the corresponding
    table if the table has two nested triggers that convert the key value to INTEGER
    and back to TEXT again.
    Ticket [https://www.sqlite.org/src/info/34cd55d68e0e6e7c9a0711aab81a2ee3c354b4c0|34cd55d68e0]

<li>SQLITE_SOURCE_ID: "2015-05-20 18:17:19 2ef4f3a5b1d1d0c4338f8243d40a2452cc1f7fe4"
<li>SHA1 for sqlite3.c: 638abb77965332c956dbbd2c8e4248e84da4eb63
} {patchagainst 2 patchagainst 1}

<li>SQLITE_SOURCE_ID: "2015-05-09 12:14:55 05b4b1f2a937c06c90db70c09890038f6c98ec40"
<li>SHA1 for sqlite3.c: 85e4e1c08c7df28ef61bb9759a0d466e0eefbaa2
} {patchagainst 1}

chng {2015-05-07 (3.8.10)} {
<li>Added the [sqldiff.exe] utility program for computing the differences between two
    SQLite database files.
<li>Added the [matchinfo y flag] to the
    [matchinfo()] function of [FTS3].
<li>Performance improvements for [ORDER BY], [VACUUM], [CREATE INDEX],
    [PRAGMA integrity_check], and [PRAGMA quick_check].
<li>Fix many obscure problems discovered while [SQL fuzzing].
<li>Identify all methods for important objects in the interface documentation.
    ([sqlite3_context|example])
<li>Made the [American Fuzzy Lop fuzzer]

    [sqlite3_blob_read()] and [sqlite3_blob_write()] interfaces.
<li>Ensure that prepared statements automatically reset on extended
    error codes of SQLITE_BUSY and SQLITE_LOCKED even when compiled
    using [SQLITE_OMIT_AUTORESET].
<li>Correct miscounts in the sqlite3_analyzer.exe utility related
    to WITHOUT ROWID tables.
<li>Added the ".dbinfo" command to the [command-line shell].
<li>Improve the performance of fts3/4 queries that use the OR operator
    and at least one auxiliary fts function.
<li>Fix a bug in the fts3 snippet() function causing it to omit
    leading separator characters from snippets that begin with the
    first token in a column.
<li>SQLITE_SOURCE_ID: "2015-04-08 12:16:33 8a8ffc862e96f57aa698f93de10dee28e69f6e09"
<li>SHA1 for sqlite3.c: 49f1c3ae347e1327b5aaa6c7f76126bdf09c6f42
}

chng {2015-02-25 (3.8.8.3)} {
<li>Fix a bug (ticket
    [https://www.sqlite.org/src/info/2326c258d02ead33|2326c258d02ead33]) that can lead
    to incorrect results if the qualifying constraint of a [partial index] appears in the
    ON clause of a LEFT JOIN.
<li>Added the ability to link against the
    "[https://github.com/antirez/linenoise|linenoise]"
    command-line editing library in unix builds of the [command-line shell].

<li>SQLITE_SOURCE_ID: "2015-02-25 13:29:11 9d6c1880fb75660bbabd693175579529785f8a6b"
<li>SHA1 for sqlite3.c: 74ee38c8c6fd175ec85a47276dfcefe8a262827a
} {patchagainst 3 patchagainst 2 patchagainst 1}

    [https://www.sqlite.org/src/info/c5ea805691bfc4204b1cb9e|c5ea805691bfc4204b1cb9e].
<li>Fix data races that might occur under stress when running with many threads
    in [shared cache mode] where some of the threads are opening and
    closing connections.
<li>Fix obscure crash bugs found by
    [http://lcamtuf.coredump.cx/afl/|american fuzzy lop].  Ticket
    [https://www.sqlite.org/src/info/a59ae93ee990a55|a59ae93ee990a55].
<li>Work around a GCC optimizer bug (for gcc 4.2.1 on MacOS 10.7) that caused the
    [R-Tree extension] to compute incorrect results when compiled with -O3.
<p><b>Other changes:</b>
<li>Disable the use of the strchrnul() C-library routine unless it is
    specifically enabled using the -DHAVE_STRCHRNULL compile-time option.
<li>Improvements to the effectiveness and accuracy of the
    [likelihood()], [likely()], and [unlikely()] SQL hint functions.

<li>SHA1 for sqlite3.c: 0a56693a3c24aa3217098afab1b6fecccdedfd23
}

chng {2014-12-05 (3.8.7.3)} {
<li>Bug fix: Ensure the cached KeyInfo objects (an internal abstraction not visible to the
    application) do not go stale when operating in [shared cache mode] and frequently closing
    and reopening some database connections while leaving other database connections on the
    same shared cache open continuously.  Ticket
    [https://www.sqlite.org/src/info/e4a18565a36884b00edf|e4a18565a36884b00edf].
<li>Bug fix: Recognize that any column in the right-hand table of a LEFT JOIN can be
    NULL even if the column has a NOT NULL constraint.  Do not apply optimizations that
    assume the column is never NULL.  Ticket
    [https://www.sqlite.org/src/info/6f2222d550f5b0ee7ed|6f2222d550f5b0ee7ed].

<li>SQLITE_SOURCE_ID: "2014-12-05 22:29:24 647e77e853e81a5effeb4c33477910400a67ba86"
<li>SHA1 for sqlite3.c: 3ad2f5ba3a4a3e3e51a1dac9fda9224b359f0261
}

chng {2014-11-18 (3.8.7.2)} {
<li>Enhance the [ROLLBACK] command so that pending queries are allowed to continue as long
    as the schema is unchanged.  Formerly, a ROLLBACK would cause all pending queries to
    fail with an [SQLITE_ABORT] or [SQLITE_ABORT_ROLLBACK] error.  That error is still returned
    if the ROLLBACK modifies the schema.
<li>Bug fix: Make sure that NULL results from OP_Column are fully and completely NULL and
    do not have the MEM_Ephem bit set.
    Ticket [http://www.sqlite.org/src/info/094d39a4c95ee4|094d39a4c95ee4].
<li>Bug fix:  The %c format in sqlite3_mprintf() is able to handle precisions greater than 70.
<li>Bug fix:  Do not automatically remove the DISTINCT keyword from a SELECT that forms
    the right-hand side of an IN operator since it is necessary if the SELECT also
    contains a LIMIT.
    Ticket [http://www.sqlite.org/src/info/db87229497|db87229497].

<li>SQLITE_SOURCE_ID: "2014-11-18 20:57:56 2ab564bf9655b7c7b97ab85cafc8a48329b27f93"
<li>SHA1 for sqlite3.c: b2a68d5783f48dba6a8cb50d8bf69b238c5ec53a
}

<li>SQLITE_SOURCE_ID: "2014-10-29 13:59:56 3b7b72c4685aa5cf5e675c2c47ebec10d9704221"
<li>SHA1 for sqlite3.c: 2d25bd1a73dc40f538f3a81c28e6efa5999bdf0c
}

chng {2014-10-17 (3.8.7)} {
<p><b>Performance Enhancements:</b>
<li>Many micro-optimizations result in 20.3% more work for the same number
    of CPU cycles relative to the previous release.
    The cumulative performance increase since [version 3.8.0] is 61%.
    (Measured using
    [http://valgrind.org/docs/manual/cg-manual.html|cachegrind] on the
    [http://www.sqlite.org/src/artifact/83f6b3318f7ee|speedtest1.c] workload on
    Ubuntu 13.10 x64 with gcc 4.8.1 and -Os. Your performance may vary.)
<li>The sorter can use auxiliary helper threads to increase real-time response.
    This feature is off by default and may be
    enabled using the [PRAGMA threads] command or the [SQLITE_DEFAULT_WORKER_THREADS]
    compile-time option.

<li>Fix a bug in [sqlite3_trace()] that was causing it to sometimes fail to print
    an SQL statement if that statement needed to be re-prepared.
    Ticket [http://www.sqlite.org/src/info/11d5aa455e0d98f3c1e6a08|11d5aa455e0d98f3c1e6a08]
<li>Fix a faulty assert() statement.
    Ticket [http://www.sqlite.org/src/info/369d57fb8e5ccdff06f1|369d57fb8e5ccdff06f1]
<p><b>Test, Debug, and Analysis Changes:</b>
<li>Show ASCII-art abstract syntax tree diagrams using the ".selecttrace"
    and ".wheretrace" commands in the
    [command-line shell] when compiled with [SQLITE_DEBUG], SQLITE_ENABLE_SELECTTRACE,
    and SQLITE_ENABLE_WHERETRACE.  Also provide the sqlite3TreeViewExpr() and
    sqlite3TreeViewSelect() entry points that can be invoked from with the
    debugger to show the parse tree when stopped at a breakpoint.
<li>Drop support for SQLITE_ENABLE_TREE_EXPLAIN.  The SELECTTRACE mechanism provides
    more useful diagnostics information.
<li>New options to the [command-line shell] for configuring auxiliary

    Ticket [http://www.sqlite.org/src/info/2ea3e9fe63 | 2ea3e9fe63]
<li>Crash when calling undocumented SQL function sqlite_rename_parent()
    with NULL parameters.
    Ticket [http://www.sqlite.org/src/info/264b970c4379fd | 264b970c43]
<li>ORDER BY ignored if the query has an identical GROUP BY.
    Ticket [http://www.sqlite.org/src/info/b75a9ca6b0499 |  b75a9ca6b0]
<li>The group_concat(x,'') SQL function returns NULL instead of an empty string
    when all inputs are empty strings.
    Ticket [http://www.sqlite.org/src/info/55746f9e65f85 |  55746f9e65]
<li>Fix a bug in the VDBE code generator that caused crashes when
    doing an INSERT INTO ... SELECT statement where the number of columns
    being inserted is larger than the number of columns in the destination
    table.
    Ticket [http://www.sqlite.org/src/info/e9654505cfda9 | e9654505cfd]
<li>Fix a problem in CSV import in the [command-line shell]

    being too large.

<li>SQLITE_SOURCE_ID: "2014-06-04 14:06:34 b1ed4f2a34ba66c29b130f8d13e9092758019212"
<li>SHA1 for sqlite3.c: 7bc194957238c61b1a47f301270286be5bc5208c
}

chng {2014-04-03 (3.8.4.3)} {
<li>Add a
    [http://www.sqlite.org/src/fdiff?sbs=1&v1=7d539cedb1c&v2=ebad891b7494d&smhdr|one-character fix]
    for a problem that might cause incorrect query results on a query that mixes
    DISTINCT, GROUP BY in a subquery, and ORDER BY.
    [http://www.sqlite.org/src/info/98825a79ce1456863|Ticket 98825a79ce14].
<li>SQLITE_SOURCE_ID: "2014-04-03 16:53:12 a611fa96c4a848614efe899130359c9f6fb889c3"
<li>SHA1 for sqlite3.c: 310a1faeb9332a3cd8d1f53b4a2e055abf537bdc
} {patchagainst 3 patchagainst 2 patchagainst 1}

<li>Add the ".clone" and ".save" commands to the command-line shell.
<li>Update the banner on the command-line shell to alert novice users when they
    are using an ephemeral in-memory database.
<li>Fix editline support in the command-line shell.
<li>Add support for coverage testing of VDBE programs using the
    [SQLITE_TESTCTRL_VDBE_COVERAGE] verb of [sqlite3_test_control()].
<li>Update the _FILE_OFFSET_BITS macro so that builds work again on QNX.
<li>Change the datatype of SrcList.nSrc from type u8 to type int to work around
    an issue in the C compiler on AIX.
<li>Get extension loading working on Cygwin.
<li>Bug fix: Fix the [char()] SQL function so that it returns an empty string
    rather than an "out of memory" error when called with zero arguments.
<li>Bug fix: DISTINCT now recognizes that a [zeroblob] and a blob of all
    0x00 bytes are the same thing.
    [http://www.sqlite.org/src/info/fccbde530a | Ticket &#91;fccbde530a&#93;]
<li>Bug fix: Compute the correct answer for queries that contain an IS NOT NULL
    term in the WHERE clause and also contain an OR term in the WHERE clause and
    are compiled with [SQLITE_ENABLE_STAT4].
    [http://www.sqlite.org/src/info/4c86b126f2 | Ticket &#91;4c86b126f2&#93;]
<li>Bug fix: Make sure "rowid" columns are correctly resolved in joins between
    normal tables and WITHOUT ROWID tables.

<li>Improvements to the comments in the VDBE byte-code display when running [EXPLAIN].
<li>Add the "%token_class" directive to [Lemon parser generator] and use it to simplify
    the grammar.
<li>Change the [Lemon] source code to avoid calling C-library functions that OpenBSD
    considers dangerous.  (Ex: sprintf).
<li>Bug fix: In the [command-line shell] CSV import feature, do not end a field
    when an escaped double-quote occurs at the end of a CRLN line.
<li>SQLITE_SOURCE_ID:
    "2014-02-03 13:52:03 e816dd924619db5f766de6df74ea2194f3e3b538"
<li>SHA1 for sqlite3.c: 98a07da78f71b0275e8d9c510486877adc31dbee
}

chng {2013-12-06 (3.8.2)} {
<li>Changed the defined behavior for the [CAST expression] when floating point values
    greater than  +9223372036854775807 are cast into integers so that the
    result is the largest possible integer, +9223372036854775807, instead of
    the smallest possible integer, -9223372036854775808.  After this change,
    CAST(9223372036854775809.0 as INT) yields +9223372036854775807 instead
    of -9223372036854775808.
    <b><big>&larr;</big>&nbsp;Potentially Incompatible Change!</b>
<li>Added support for [WITHOUT ROWID] tables.
<li>Added the [skip-scan optimization] to the query planner.
<li>Extended the [virtual table] interface, and in particular the
    [sqlite3_index_info] object to allow a virtual table to report its estimate

<li>Factor constant subexpressions in inner loops out to the initialization code
    in prepared statements.
<li>Enhanced the ".explain" output formatting of the [command-line shell]
    so that loops are indented to better show the structure of the program.
<li>Enhanced the ".timer" feature of the [command-line shell] so that it
    shows wall-clock time in addition to system and user times.

<li>SQLITE_SOURCE_ID:
    "2013-12-06 14:53:30 27392118af4c38c5203a04b8013e1afdb1cebd0d"
<li>SHA1 for sqlite3.c: 6422c7d69866f5ea3db0968f67ee596e7114544e
}

chng {2013-10-17 (3.8.1)} {
<li>Added the [unlikely()] and [likelihood()] SQL functions to be used
    as hints to the query planner.
<li>Enhancements to the query planner:
<ol type='a'>
  <li>Take into account the fact WHERE clause terms that cannot be used with indices
      still probably reduce the number of output rows.
  <li>Estimate the sizes of table and index rows and use the smallest applicable B-Tree
      for full scans and "count(*)" operations.
</ol>
<li>Added the [soft_heap_limit pragma].
<li>Added support for [SQLITE_ENABLE_STAT4]
<li>Added support for "sz=NNN" parameters at the end of
    [sqlite_stat1 | sqlite_stat1.stat] fields
    used to specify the average length in bytes for table and index rows.
<li>Avoid running foreign-key constraint checks on an UPDATE if none of the
    modified columns are associated with foreign keys.
<li>Added the [SQLITE_MINIMUM_FILE_DESCRIPTOR] compile-time option
<li>Added the win32-longpath VFS on windows, permitting filenames up to 32K
    characters in length.

    TMPDIR environment variable.  The [sqlite3_temp_directory] global variable
    still has higher precedence than both environment variables, however.
<li>Added the [PRAGMA stats] statement.
<li><b>Bug fix:</b> Return the correct answer for "SELECT count(*) FROM table" even if
    there is a [partial index] on the table. Ticket
    [http://www.sqlite.org/src/info/a5c8ed66ca|a5c8ed66ca].

<li>SQLITE_SOURCE_ID:
    "2013-10-17 12:57:35 c78be6d786c19073b3a6730dfe3fb1be54f5657a"
<li>SHA1 for sqlite3.c: 0a54d76566728c2ba96292a49b138e4f69a7c391
}

chng {2013-09-03 (3.8.0.2)} {
<li>Fix a bug in the optimization that attempts to omit unused LEFT JOINs

<li>SQLITE_SOURCE_ID:
    "2013-09-03 17:11:13 7dd4968f235d6e1ca9547cda9cf3bd570e1609ef"
<li>SHA1 for sqlite3.c: 6cf0c7b46975a87a0dc3fba69c229a7de61b0c21
} {inadditionto 2 inadditionto 1}

chng {2013-08-29 (3.8.0.1)} {
<li>Fix an off-by-one error that caused quoted empty string at the end of a
CRNL-terminated line of CSV input to be misread by the command-line shell.
<li>Fix a query planner bug involving a LEFT JOIN with a BETWEEN or LIKE/GLOB
constraint and then another INNER JOIN to the right that involves an OR constraint.
<li>Fix a query planner bug that could result in a segfault when querying tables
with a UNIQUE or PRIMARY KEY constraint with more than four columns.

<li>SQLITE_SOURCE_ID:
    "2013-08-29 17:35:01 352362bc01660edfbda08179d60f09e2038a2f49"
<li>SHA1 for sqlite3.c: 99906bf63e6cef63d6f3d7f8526ac4a70e76559e
} {inadditionto 1}

chng {2013-08-26 (3.8.0)} {
<li>Add support for [partial indexes]</li>
<li>Cut-over to the [next generation query planner] for faster and better query plans.
<li>The [EXPLAIN QUERY PLAN] output no longer shows an estimate of the number of
    rows generated by each loop in a join.
<li>Added the [FTS4 notindexed option], allowing non-indexed columns in an FTS4 table.
<li>Added the [SQLITE_STMTSTATUS_VM_STEP] option to [sqlite3_stmt_status()].
<li>Added the [cache_spill pragma].
<li>Added the [query_only pragma].
<li>Added the [defer_foreign_keys pragma] and the
    [sqlite3_db_status](db, [SQLITE_DBSTATUS_DEFERRED_FKS],...) C-language interface.
<li>Added the "percentile()" function as a [loadable extension] in the ext/misc
    subdirectory of the source tree.
<li>Added the [SQLITE_ALLOW_URI_AUTHORITY] compile-time option.
<li>Add the [sqlite3_cancel_auto_extension(X)] interface.
<li>A running SELECT statement that lacks a FROM clause (or any other statement that
    never reads or writes from any database file) will not prevent a read
    transaction from closing.
<li>Add the [SQLITE_DEFAULT_AUTOMATIC_INDEX] compile-time option.  Setting this option
    to 0 disables automatic indices by default.
<li>Issue an [SQLITE_WARNING_AUTOINDEX] warning on the [SQLITE_CONFIG_LOG] whenever
    the query planner uses an automatic index.
<li>Added the [SQLITE_FTS3_MAX_EXPR_DEPTH] compile-time option.
<li>Added an optional 5th parameter defining the collating sequence to the
    next_char() extension SQL function.
<li>The [SQLITE_BUSY_SNAPSHOT] extended error code is returned in WAL mode when
    a read transaction cannot be upgraded to a write transaction because the read is
    on an older snapshot.
<li>Enhancements to the sqlite3_analyzer utility program to provide size
    information separately for each individual index of a table, in addition to
    the aggregate size.
<li>Allow read transactions to be freely opened and closed by SQL statements run
    from within the implementation of [application-defined SQL functions] if the
    function is called by a SELECT statement that does not access any database table.
<li>Disable the use of posix_fallocate() on all (unix) systems unless the
    HAVE_POSIX_FALLOCATE compile-time option is used.
<li>Update the ".import" command in the [command-line shell] to support multi-line
    fields and correct RFC-4180 quoting and to issue warning and/or error messages
    if the input text is not strictly RFC-4180 compliant.
<li>Bug fix: In the [unicode61] tokenizer of [FTS4], treat all private code points
    as identifier symbols.
<li>Bug fix: Bare identifiers in ORDER BY clauses bind more tightly to output column
    names, but identifiers in expressions bind more tightly to input column names.
    Identifiers in GROUP BY clauses always prefer output column names, however.
<li>Bug fixes: Multiple problems in the legacy query optimizer were fixed by the
    move to [NGQP].

<li>SQLITE_SOURCE_ID:
    "2013-08-26 04:50:08 f64cd21e2e23ed7cff48f7dafa5e76adde9321c2"
<li>SHA1 for sqlite3.c: b7347f4b4c2a840e6ba12040093d606bd16ea21e
}

chng {2013-05-20 (3.7.17)} {
<li>Add support for [memory-mapped I/O].
<li>Add the [sqlite3_strglob()] convenience interface.
<li>Assigned the integer at offset 68 in the [database header] as the
    [Application ID] for when SQLite is used as an [application file-format].
    Added the [PRAGMA application_id] command to query and set the Application ID.
<li>Report rollback recovery in the [error log] as SQLITE_NOTICE_RECOVER_ROLLBACK.
    Change the error log code for WAL recover from
    SQLITE_OK to SQLITE_NOTICE_RECOVER_WAL.
<li>Report the risky uses of [unlinked database files] and
   [database filename aliasing] as SQLITE_WARNING messages in the [error log].
<li>Added the [SQLITE_TRACE_SIZE_LIMIT] compile-time option.
<li>Increase the default value of [SQLITE_MAX_SCHEMA_RETRY] to 50 and make sure
    that it is honored in every place that a schema change might force a statement
    retry.
<li>Add a new test harness called "mptester" used to verify correct operation
    when multiple processes are using the same database file at the same time.

        with no code changes.
    <li>The shared library filename passed to [sqlite3_load_extension()] may
        omit the filename suffix, and an appropriate architecture-dependent
        suffix (".so", ".dylib", or ".dll") will be added automatically.
    </ol>
<li>Added many new loadable extensions to the source tree, including
    amatch, closure, fuzzer, ieee754, nextchar, regexp, spellfix,
    and wholenumber.  See header comments on each extension source file
    for further information about what that extension does.
<li>Enhance [FTS3] to avoid using excess stack space when there are a huge
    number of terms on the right-hand side of the MATCH operator.  A side-effect
    of this change is that the MATCH operator can only accommodate 12 NEAR
    operators at a time.
<li>Enhance the [fts4aux] virtual table so that it can be a TEMP table.
<li>Added the [fts3tokenize virtual table] to the [full-text search] logic.
<li>Query planner enhancement: Use the transitive property of constraints
    to move constraints into the outer loops of a join whenever possible,
    thereby reducing the amount of work that needs to occur in inner loops.
<li>Discontinue the use of posix_fallocate() on unix, as it does not work on all
    filesystems.
<li>Improved tracing and debugging facilities in the Windows [VFS].
<li>Bug fix: Fix a potential <b>database corruption bug</b>
    in [shared cache mode] when one
    [database connection] is closed while another is in the middle of a write
    transaction.
    Ticket [http://www.sqlite.org/src/info/e636a050b7 | e636a050b7]
<li>Bug fix:
    Only consider AS names from the result set as candidates for resolving
    identifiers in the WHERE clause if there are no other matches. In the
    ORDER BY clause, AS names take priority over any column names.
    Ticket [http://www.sqlite.org/src/info/2500cdb9be05 | 2500cdb9be05]
<li>Bug fix: Do not allow a virtual table to cancel the ORDER BY clause unless
    all outer loops are guaranteed to return no more than one row result.
    Ticket [http://www.sqlite.org/src/info/ba82a4a41eac1 | ba82a4a41eac1].
<li>Bug fix: Do not suppress the ORDER BY clause on a virtual table query if
    an IN constraint is used.
    Ticket [http://www.sqlite.org/src/info/f69b96e3076e | f69b96e3076e].
<li>Bug fix: The [command-line shell] gives an exit code of 0 when terminated
    using the ".quit" command.
<li>Bug fix: Make sure [PRAGMA] statements appear in [sqlite3_trace()] output.
<li>Bug fix: When a [compound query] that uses an ORDER BY clause
    with a [COLLATE operator], make sure that the sorting occurs
    according to the specified collation and that the comparisons associate with
    the compound query use the native collation.  Ticket
    [http://www.sqlite.org/src/info/6709574d2a8d8 | 6709574d2a8d8].
<li>Bug fix: Makes sure the [sqlite3_set_authorizer | authorizer] callback gets
    a valid pointer to the string "ROWID" for the column-name parameter when
    doing an [UPDATE] that changes the rowid.  Ticket
    [http://www.sqlite.org/src/info/0eb70d77cb05bb2272 | 0eb70d77cb05bb2272]
<li>Bug fix: Do not move WHERE clause terms inside OR expressions that are
    contained within an ON clause of a LEFT JOIN.  Ticket
    [http://www.sqlite.org/src/info/f2369304e4 | f2369304e4]
<li>Bug fix: Make sure an error is always reported when attempting to preform
    an operation that requires a [collating sequence] that is missing.
    Ticket [http://www.sqlite.org/src/info/0fc59f908b | 0fc59f908b]

<li>SQLITE_SOURCE_ID:
    "2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668"
<li>SHA1 for sqlite3.c: 246987605d0503c700a08b9ee99a6b5d67454aab
}

chng {2013-04-12 (3.7.16.2)} {
<li>Fix a bug (present since version 3.7.13) that could result in database corruption
    on windows if two or more processes try to access the same database file at the
    same time and immediately after third process crashed in the middle of committing
    to that same file.  See ticket
    [http://www.sqlite.org/src/info/7ff3120e4f | 7ff3120e4f] for further
    information.

<li>SQLITE_SOURCE_ID:
    "2013-04-12 11:52:43 cbea02d93865ce0e06789db95fd9168ebac970c7"
<li>SHA1 for sqlite3.c: d466b54789dff4fb0238b9232e74896deaefab94
} {inadditionto 2 inadditionto 1}

chng {2013-03-29 (3.7.16.1)} {
<li>Fix for a bug in the ORDER BY optimizer that was introduced in
    [version 3.7.15] which would sometimes optimize out the sorting step

<li>Fix a long-standing bug in the storage engine that would (very rarely)
    cause a spurious report of an SQLITE_CORRUPT error but which was otherwise
    harmless.
    Ticket [http://www.sqlite.org/src/info/6bfb98dfc0c | 6bfb98dfc0c].
<li>The SQLITE_OMIT_MERGE_SORT option has been removed.  The merge sorter is
    now a required component of SQLite.
<li>Fixed lots of spelling errors in the source-code comments
<li>SQLITE_SOURCE_ID:
    "2013-03-29 13:44:34 527231bc67285f01fb18d4451b28f61da3c4e39d"
<li>SHA1 for sqlite3.c: 7a91ceceac9bcf47ceb8219126276e5518f7ff5a
} {inadditionto 1}

chng {2013-03-18 (3.7.16)} {
<li>Added the [PRAGMA foreign_key_check] command.
<li>Added new extended error codes for all SQLITE_CONSTRAINT errors
<li>Added the SQLITE_READONLY_ROLLBACK extended error code for when a database
    cannot be opened because it needs rollback recovery but is read-only.
<li>Added SQL functions [unicode(A)] and [char(X1,...,XN)].
<li>Performance improvements for [PRAGMA incremental_vacuum], especially in
    cases where the number of free pages is greater than what will fit on a
    single trunk page of the freelist.
<li>Improved optimization of queries containing aggregate min() or max().
<li>Enhance virtual tables so that they can potentially use an index when
    the WHERE clause contains the IN operator.
<li>Allow indices to be used for sorting even if prior terms of the index
    are constrained by IN operators in the WHERE clause.
<li>Enhance the [PRAGMA table_info] command so that the "pk" column is an

    shutting down the database connection.
<li>Improved error messages for invalid boolean arguments to dot-commands
    in the [command-line shell].
<li>Improved error messages for "foreign key mismatch" showing the names of
    the two tables involved.
<li>Remove all uses of umask() in the unix VFS.
<li>Added the [PRAGMA vdbe_addoptrace] and [PRAGMA vdbe_debug] commands.
<li>Change to use strncmp() or the equivalent instead of memcmp() when
    comparing non-zero-terminated strings.
<li>Update cygwin interfaces to omit deprecated API calls.
<li>Enhance the [spellfix1] extension so that the edit distance cost table can
    be changed at runtime by inserting a string like 'edit_cost_table=TABLE'
    into the "command" field.

<li>Bug fix: repair a long-standing problem that could cause incorrect query
    results in a 3-way or larger join that compared INTEGER fields against TEXT
    fields in two or more places.
    Ticket [http://www.sqlite.org/src/info/fc7bd6358f | fc7bd6358f]
<li>Bug fix: Issue an error message if the 16-bit reference counter on a
    view overflows due to an overly complex query.
<li>Bug fix: Avoid leaking memory on LIMIT and OFFSET clauses in deeply
    nested UNION ALL queries.
<li>Bug fix: Make sure the schema is up-to-date prior to running pragmas
    table_info, index_list, index_info, and foreign_key_list.

<li>SQLITE_SOURCE_ID:
    "2013-03-18 11:39:23 66d5f2b76750f3520eb7a495f6247206758f5b90"
<li>SHA1 for sqlite3.c: 7308ab891ca1b2ebc596025cfe4dc36f1ee89cf6
}

chng {2013-01-09 (3.7.15.2)} {
<li>Fix a bug, introduced in [version 3.7.15], that causes an ORDER BY clause
    to be optimized out of a three-way join when the ORDER BY is actually
    required.	
    Ticket [http://www.sqlite.org/src/info/598f5f7596b055 | 598f5f7596b055]

<li>SQLITE_SOURCE_ID:
    "2013-01-09 11:53:05 c0e09560d26f0a6456be9dd3447f5311eb4f238f"
<li>SHA1 for sqlite3.c: 5741f47d1bc38aa0a8c38f09e60a5fe0031f272d
}

chng {2012-12-19 (3.7.15.1)} {
<li>Fix a bug, introduced in [version 3.7.15], that causes a segfault if
    the AS name of a result column of a SELECT statement is used as a logical
    term in the WHERE clause.  Ticket
    [http://www.sqlite.org/src/info/a7b7803e8d1e869 | a7b7803e8d1e869].

<li>SQLITE_SOURCE_ID:
    "2012-12-19 20:39:10 6b85b767d0ff7975146156a99ad673f2c1a23318"
<li>SHA1 for sqlite3.c: bbbaa68061e925bd4d7d18d7e1270935c5f7e39a
}

chng {2012-12-12 (3.7.15)} {
<li>Added the [sqlite3_errstr()] interface.
<li>Avoid invoking the [sqlite3_trace()] callback multiple times when a

<li>Bug fix: SQL functions created using the TCL interface honor the
    "nullvalue" setting.
<li>Bug fix: Fix a 32-bit overflow problem on CREATE INDEX for databases
    larger than 16GB.
<li>Bug fix: Avoid segfault when using the [COLLATE operator] inside of a
    [CHECK constraint] or [view] in [shared cache mode].

<li>SQLITE_SOURCE_ID:
    "2012-12-12 13:36:53 cd0b37c52658bfdf992b1e3dc467bae1835a94ae"
<li>SHA1 for sqlite3.c: 2b413611f5e3e3b6ef5f618f2a9209cdf25cbcff"
}

chng {2012-10-04 (3.7.14.1)} {
<li>Fix a bug (ticket
<a href="http://www.sqlite.org/src/tktview/d02e1406a58ea02d">&#91;d02e1406a58ea02d]&#93;</a>)
that causes a segfault on a LEFT JOIN that includes an OR in the ON clause.
<li>Work around a bug in the optimizer in the VisualStudio-2012 compiler that
causes invalid code to be generated when compiling SQLite on ARM.
<li>Fix the TCL interface so that the "nullvalue" setting is honored for
TCL implementations of SQL functions.
<li>SQLITE_SOURCE_ID:
    "2012-10-04 19:37:12 091570e46d04e84b67228e0bdbcd6e1fb60c6bdb"
<li>SHA1 for sqlite3.c: 62aaecaacab3a4bf4a8fe4aec1cfdc1571fe9a44
}

chng {2012-09-03 (3.7.14)} {
<li>Drop built-in support for OS/2. If you need to upgrade an OS/2
    application to use this or a later version of SQLite,
    then add an application-defined [VFS] using the
    [sqlite3_vfs_register()] interface.  The code removed in this release can
    serve as a baseline for the application-defined VFS.
<li>Ensure that floating point values are preserved exactly when reconstructing
    a database from the output of the ".dump" command of the
    [command-line shell].
<li>Added the [sqlite3_close_v2()] interface.
<li>Updated the [command-line shell] so that it can be built using
    [SQLITE_OMIT_FLOATING_POINT] and [SQLITE_OMIT_AUTOINIT].
<li>Improvements to the windows makefiles and build processes.
<li>Enhancements to [PRAGMA integrity_check] and [PRAGMA quick_check] so that
    they can optionally check just a single attached database instead of all
    attached databases.
<li>Enhancements to [WAL mode] processing that ensure that at least one
    valid read-mark is available at all times, so that read-only processes
    can always read the database.
<li>Performance enhancements in the sorter used by ORDER BY and CREATE INDEX.
<li>Added the [SQLITE_DISABLE_FTS4_DEFERRED] compile-time option.
<li>Better handling of aggregate queries where the aggregate functions are
    contained within subqueries.
<li>Enhance the query planner so that it will try to use a [covering index]
    on queries that make use of [or optimization].
<li>SQLITE_SOURCE_ID:
    "2012-09-03 15:42:36 c0d89d4a9752922f9e367362366efde4f1b06f2a"
<li>SHA1 for sqlite3.c: 5fdf596b29bb426001f28b488ff356ae14d5a5a6
}

chng {2012-06-11 (3.7.13)} {
<li>[in-memory database | In-memory databases] that are specified using
    [URI filenames] are allowed to use [in-memory shared-cache | shared cache],

<li>Adjust the unix driver to avoid unnecessary calls to fchown().
<li>Add interfaces sqlite3_quota_ferror() and sqlite3_quota_file_available()
    to the test_quota.c module.
<li>The [sqlite3_create_module()] and [sqlite3_create_module_v2()] interfaces
    return SQLITE_MISUSE on any attempt to overload or replace a [virtual table]
    module.  The destructor is always called in this case, in accordance with
    historical and current documentation.
<li>SQLITE_SOURCE_ID:
    "2012-06-11 02:05:22 f5b5a13f7394dc143aa136f1d4faba6839eaa6dc"
<li>SHA1 for sqlite3.c: ff0a771d6252545740ba9685e312b0e3bb6a641b
}

chng {2012-05-22 (3.7.12.1)} {
<li>Fix a bug
    [http://www.sqlite.org/src/info/c2ad16f997ee9c | (ticket c2ad16f997)]
    in the 3.7.12 release that can cause a segfault for certain
    obscure nested aggregate queries.
<li>Fix various other minor test script problems.
<li>SQLITE_SOURCE_ID:
    "2012-05-22 02:45:53 6d326d44fd1d626aae0e8456e5fa2049f1ce0789"
<li>SHA1 for sqlite3.c: d494e8d81607f0515d4f386156fb0fd86d5ba7df
}

chng {2012-05-14 (3.7.12)} {
<li>Add the [SQLITE_DBSTATUS_CACHE_WRITE] option for [sqlite3_db_status()].
<li>Optimize the [typeof()] and [length()] SQL functions so that they avoid

<li>Bug fix: Do not discard the DISTINCT as superfluous unless a subset of
    the result set is subject to a UNIQUE constraint <em>and</em> it none
    of the columns in that subset can be NULL.
    Ticket [http://www.sqlite.org/src/info/385a5b56b9 | 385a5b56b9].
<li>Bug fix: Do not optimize away an ORDER BY clause that has the same terms
    as a UNIQUE index unless those terms are also NOT NULL.
    Ticket [http://www.sqlite.org/src/info/2a5629202f | 2a5629202f].
<li>SQLITE_SOURCE_ID:
    "2012-05-14 01:41:23 8654aa9540fe9fd210899d83d17f3f407096c004"
<li>SHA1 for sqlite3.c: 57e2104a0f7b3f528e7f6b7a8e553e2357ccd2e1

}

chng {2012-03-20 (3.7.11)} {
<li>Enhance the [INSERT] syntax to allow multiple rows to be inserted
    via the VALUES clause.
<li>Enhance the [CREATE VIRTUAL TABLE] command to support the
    IF NOT EXISTS clause.
<li>Added the [sqlite3_stricmp()] interface as a counterpart to
    [sqlite3_strnicmp()].
<li>Added the [sqlite3_db_readonly()] interface.
<li>Added the [SQLITE_FCNTL_PRAGMA] file control, giving [VFS] implementations
    the ability to add new [PRAGMA] statements or to override built-in
    PRAGMAs.
<li>Queries of the form:  "SELECT max(x), y FROM table" returns the
    value of y on the same row that contains the maximum x value.
<li>Added support for the [FTS4 languageid option].
<li>Documented support for the [FTS4 content option].  This feature has
    actually been in the code since [version 3.7.9] but is only now considered
    to be officially supported.
<li>Pending statements no longer block [ROLLBACK].  Instead, the pending
    statement will return SQLITE_ABORT upon next access after the ROLLBACK.
<li>Improvements to the handling of CSV inputs in the [command-line shell]
<li>Fix a [http://www.sqlite.org/src/info/b7c8682cc1|bug] introduced
    in [version 3.7.10] that might cause a LEFT JOIN
    to be incorrectly converted into an INNER JOIN if the WHERE clause
    indexable terms connected by OR.

<li>SQLITE_SOURCE_ID:
    "2012-03-20 11:35:50 00bb9c9ce4f465e6ac321ced2a9d0062dc364669"
<li>SHA1 for sqlite3.c: d460d7eda3a9dccd291aed2a9fda868b9b120a10
}

chng {2012-01-16 (3.7.10)} {
<li>The default [schema format number] is changed from 1 to 4.
    This means that, unless

    initially empty.
<li>Enhanced the windows [VFS] so that all system calls can be overridden
    using the xSetSystemCall interface.
<li>Updated the "unix-dotfile" [VFS] to use locking directories with mkdir()
    and rmdir() instead of locking files with open() and unlink().
<li>Enhancements to the test_quota.c extension to support stdio-like interfaces
    with quotas.
<li>Change the unix [VFS] to be tolerant of read() system calls that return
    less then the full number of requested bytes.
<li>Change both unix and windows [VFSes] to report a sector size of 4096
    instead of the old default of 512.
<li>In the [TCL Interface], add the -uri option to the "sqlite3" TCL command
    used for creating new database connection objects.
<li>Added the [SQLITE_TESTCTRL_EXPLAIN_STMT] test-control option with the
    [SQLITE_ENABLE_TREE_EXPLAIN] compile-time option to enable the

<li><b>Bug fix:</b>
    Change the VDBE so that all registers are initialized to Invalid
    instead of NULL.
    Ticket [http://www.sqlite.org/src/info/7bbfb7d442 | 7bbfb7d442]
<li><b>Bug fix:</b>
    Fix problems that can result from 32-bit integer overflow.
    Ticket [http://www.sqlite.org/src/info/ac0ff496b7e2 | ac00f496b7e2]
<li>SQLITE_SOURCE_ID:
    "2012-01-16 13:28:40 ebd01a8deffb5024a5d7494eef800d2366d97204"
<li>SHA1 for sqlite3.c: 6497cbbaad47220bd41e2e4216c54706e7ae95d4
}

chng {2011-11-01 (3.7.9)} {
<li>If a search token (on the right-hand side of the MATCH operator) in
    [FTS4] begins with "&#94;" then that token must be the first in its field

    indicates to the VFS that the current transaction will overwrite the
    entire database file.
<li>Increase the default [lookaside memory allocator] allocation size from
    100 to 128 bytes.
<li>Enhanced the query planner so that it can factor terms in and out of
    OR expressions in the WHERE clause in an effort to find better indices.
<li>Added the [SQLITE_DIRECT_OVERFLOW_READ] compile-time option, causing
    [overflow pages] to be read directly from the database file,
    bypassing the [page cache].
<li>Remove limits on the magnitude of precision and width value in the
    format specifiers of the [sqlite3_mprintf()] family of string rendering
    routines.
<li>Fix a bug that prevent [ALTER TABLE | ALTER TABLE ... RENAME] from working
    on some virtual tables in a database with a UTF16 encoding.
<li>Fix a bug in ASCII-to-float conversion that causes slow performance and
    incorrect results when converting numbers with ridiculously large exponents.
<li>Fix a bug that causes incorrect results in aggregate queries that use
    multiple aggregate functions whose arguments contain complicated expressions
    that differ only in the case of string literals contained within those
    expressions.
<li>Fix a bug that prevented the [page_count] and [quick_check] pragmas from
    working correctly if their names were capitalized.
<li>Fix a bug that caused [VACUUM] to fail if the [count_changes pragma] was
    engaged.
<li>Fix a bug in [virtual table] implementation that causes a crash if
    an [FTS4] table is [DROP TABLE | dropped] inside a transaction and
    a [SAVEPOINT] occurs afterwards.
<li>SQLITE_SOURCE_ID:
    "2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e"
<li>SHA1 for sqlite3.c: becd16877f4f9b281b91c97e106089497d71bb47
}

chng {2011-09-19 (3.7.8)} {
<li> Orders of magnitude performance improvement for [CREATE INDEX] on
     very large tables.
<li> Improved the windows VFS to better defend against interference
     from anti-virus software.
<li> Improved query plan optimization when the DISTINCT keyword is present.
<li> Allow more system calls to be overridden in the unix VFS - to provide
     better support for chromium sandboxes.
<li> Increase the default size of a lookahead cache line from 100 to 128 bytes.
<li> Enhancements to the test_quota.c module so that it can track
     preexisting files.
<li> Bug fix: Virtual tables now handle IS NOT NULL constraints correctly.
<li> Bug fixes: Correctly handle nested correlated subqueries used with
     indices in a WHERE clause.
<li> SQLITE_SOURCE_ID:
    "2011-09-19 14:49:19 3e0da808d2f5b4d12046e05980ca04578f581177"
<li> SHA1 for sqlite3.c: bfcd74a655636b592c5dba6d0d5729c0f8e3b4de
}

chng {2011-06-28 (3.7.7.1)} {
<li> Fix [http://www.sqlite.org/src/info/25ee812710 | a bug] causing
     [PRAGMA case_sensitive_like] statements compiled using sqlite3_prepare()
     to fail with an [SQLITE_SCHEMA] error.
<li> SQLITE_SOURCE_ID:
    "2011-06-28 17:39:05 af0d91adf497f5f36ec3813f04235a6e195a605f"
<li> SHA1 for sqlite3.c: d47594b8a02f6cf58e91fb673e96cb1b397aace0
}

     </ol>
<li> Enhance the [ANALYZE] command to support the name of an index
     as its argument, in order to analyze just that one index.
<li> Added the "unix-excl" built-in VFS on unix and unix-like platforms.
<li> SQLITE_SOURCE_ID:
     "2011-04-12 01:58:40 f9d43fa363d54beab6f45db005abac0a7c0c47a7"
<li> SHA1 for sqlite3.c: f38df08547efae0ff4343da607b723f588bbd66b
}

chng {2011-02-01 (3.7.5)} {
<li> Added the [sqlite3_vsnprintf()] interface.
<li> Added the [SQLITE_DBSTATUS_LOOKASIDE_HIT],
     [SQLITE_DBSTATUS_LOOKASIDE_MISS_SIZE], and
     [SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL] options for the
     [sqlite3_db_status()] interface.
<li> Added the [SQLITE_OMIT_AUTORESET] compile-time option.
<li> Added the [SQLITE_DEFAULT_FOREIGN_KEYS] compile-time option.
<li> Updates to [sqlite3_stmt_readonly()] so that its result is well-defined
     for all prepared statements and so that it works with [VACUUM].
<li> Added the "-heap" option to the [command-line shell]
<li> Fix [http://www.sqlite.org/src/info/5d863f876e | a bug] involving
     frequent changes in and out of WAL mode and
     VACUUM that could (in theory) cause database corruption.
<li> Enhance the [sqlite3_trace()] mechanism so that nested SQL statements
     such as might be generated by virtual tables are shown but are shown
     in comments and without parameter expansion.  This
     greatly improves tracing output when using the FTS3/4 and/or RTREE
     virtual tables.
<li> Change the xFileControl() methods on all built-in VFSes to return
     [SQLITE_NOTFOUND] instead of [SQLITE_ERROR] for an unrecognized
     operation code.
<li> The SQLite core invokes the [SQLITE_FCNTL_SYNC_OMITTED]
     [sqlite3_file_control | file control]
     to the VFS in place of a call to xSync if the database has
     [PRAGMA synchronous] set to OFF.
}

chng {2010-12-07 (3.7.4)} {
<li> Added the [sqlite3_blob_reopen()] interface to allow an existing
     [sqlite3_blob] object to be rebound to a new row.
<li> Use the new [sqlite3_blob_reopen()] interface to improve the performance
     of FTS.
<li> [sqlite3_vfs | VFSes] that do not support shared memory are allowed
     to access [WAL] databases if [PRAGMA locking_mode] is set to EXCLUSIVE.
<li> Enhancements to [EXPLAIN QUERY PLAN].
<li> Added the [sqlite3_stmt_readonly()] interface.
<li> Added [PRAGMA checkpoint_fullfsync].
<li> Added the [SQLITE_FCNTL_FILE_POINTER] option
     to [sqlite3_file_control()].
<li> Added support for [FTS4] and enhancements
     to the FTS [matchinfo()] function.
<li> Added the test_superlock.c module which provides example
     code for obtaining an exclusive lock to a rollback or WAL database.

<li> Added the test_multiplex.c module which provides
     an example VFS that provides multiplexing (sharding)
     of a DB, splitting it over multiple files of fixed size.
<li> A [http://www.sqlite.org/src/info/80ba201079 | very obscure bug]
     associated with the [or optimization] was fixed.
}

chng {2010-10-08 (3.7.3)} {
<li> Added the [sqlite3_create_function_v2()] interface that includes a
     destructor callback.
<li> Added support for [custom r-tree queries] using application-supplied
     callback routines to define the boundary of the query region.
<li> The default page cache strives more diligently to avoid using memory
     beyond what is allocated to it by [SQLITE_CONFIG_PAGECACHE].  Or if
     using page cache is allocating from the heap, it strives to avoid
     going over the [sqlite3_soft_heap_limit64()], even if
     [SQLITE_ENABLE_MEMORY_MANAGEMENT] is not set.
<li> Added the [sqlite3_soft_heap_limit64()] interface as a replacement for
     [sqlite3_soft_heap_limit()].
<li> The [ANALYZE] command now gathers statistics on tables even if they
     have no indices.
<li> Tweaks to the query planner to help it do a better job of finding the
     most efficient query plan for each query.
<li> Enhanced the internal text-to-numeric conversion routines so that they
     work with UTF8 or UTF16, thereby avoiding some UTF16-to-UTF8 text
     conversions.
<li> Fix a problem that was causing excess memory usage with large [WAL]

content is deleted even when the [truncate optimization] applies.
<li>Improvements to "dot-command" handling in the
[Command Line Interface].
<li>Other minor bug fixes and documentation enhancements.
}

chng {2009-11-04 (3.6.20)} {
<li>Optimizer enhancement: [prepared statements] are automatically
re-compiled when a binding on the RHS of a LIKE operator changes or
when any range constraint changes under [SQLITE_ENABLE_STAT2].
<li>Various minor bug fixes and documentation enhancements.
}

chng {2009-10-30 (3.6.16.1)} {
<li>A small patch to version 3.6.16 to fix
<a href="http://www.sqlite.org/src/info/6b00e0a34c">the OP_If bug</a>.
}

chng {2009-10-14 (3.6.19)} {
<li>Added support for [foreign key constraints].  Foreign key constraints
    are disabled by default.  Use the [foreign_keys pragma] to turn them on.
<li>Generalized the IS and IS NOT operators to take arbitrary expressions
    on their right-hand side.
<li>The [TCL Interface] has been enhanced to use the
    [http://www.tcl-lang.org/cgi-bin/tct/tip/322.html | Non-Recursive Engine (NRE)]
    interface to the TCL interpreter when linked against TCL 8.6 or later.
<li>Fix a bug introduced in 3.6.18 that can lead to a segfault when an
    attempt is made to write on a read-only database.
}

chng {2009-09-11 (3.6.18)} {
<li>Versioning of the SQLite source code has transitioned from CVS to
    [http://www.fossil-scm.org/ | Fossil].
<li>Query planner enhancements.
<li>The [SQLITE_ENABLE_STAT2] compile-time option causes the [ANALYZE]
    command to collect a small histogram of each index, to help SQLite better
    select among competing range query indices.
<li>Recursive triggers can be enabled using the [PRAGMA recursive_triggers]
    statement.
<li>Delete triggers fire when rows are removed due to a
    [ON CONFLICT | REPLACE conflict resolution].  This feature is only
    enabled when recursive triggers are enabled.
<li>Added the [SQLITE_OPEN_SHAREDCACHE] and [SQLITE_OPEN_PRIVATECACHE]
    flags for [sqlite3_open_v2()] used to override the global
    [shared cache mode] settings for individual database connections.
<li>Added improved version identification features:
    C-Preprocessor macro [SQLITE_SOURCE_ID],

    the source table.
<li>Resolve race conditions when checking for a hot rollback journal.
<li>The [sqlite3_shutdown()] interface frees all mutexes under windows.
<li>Enhanced robustness against corrupt database files
<li>Continuing improvements to the test suite and fixes to obscure
    bugs and inconsistencies that the test suite improvements are
    uncovering.

}

chng {2009-05-25 (3.6.14.2)} {
<li>Fix a code generator bug introduced in [version 3.6.14].  This bug
    can cause incorrect query results under obscure circumstances.
    Ticket #3879.
}

<li>Countless minor bug fixes, documentation improvements, new and
    improved test cases, and code simplifications and cleanups.</p>
}

chng {2009-04-13 (3.6.13)} {
<li>Fix a bug in [version 3.6.12] that causes a segfault when running
    a count(*) on the sqlite_master table of an empty database. Ticket #3774.
<li>Fix a bug in [version 3.6.12] that causes a segfault that when
    inserting into a table using a DEFAULT value where there is a
    function as part of the DEFAULT value expression.  Ticket #3791.
<li>Fix data structure alignment issues on Sparc.  Ticket #3777.
<li>Other minor bug fixes.
}

chng {2009-03-31 (3.6.12)} {
<li>Fixed a bug that caused database corruption when an [incremental_vacuum] is

    query results.  Both bugs were harmless by themselves; only when
    they team up do they cause problems.  Ticket #3581.
}

chng {2009-01-12 (3.6.8)} {
<li>Added support for [SAVEPOINT | nested transactions]</li>
<li>Enhanced the query optimizer so that it is able to use
    multiple indices to efficiently process
    <a href="optoverview.html#or_opt">OR-connected constraints</a>
    in a WHERE clause.</li>
<li>Added support for parentheses in FTS3 query patterns using the
    [SQLITE_ENABLE_FTS3_PARENTHESIS] compile-time option.</li>
}

chng {2008-12-16 (3.6.7)} {

<li>Added the
  <a href="http://www.sqlite.org/src/finfo?name=tool/genfkey.c">
  source code</a> and
  <a href="http://www.sqlite.org/src/finfo?name=tool/genfkey.README">
  documentation</a> for the <b>genfkey</b> program for automatically generating
  triggers to enforce foreign key constraints.</li>
<li>Added the [SQLITE_OMIT_TRUNCATE_OPTIMIZATION] compile-time option.</li>
<li>The <a href="lang.html">SQL language documentation</a> is converted to use
<a href="syntaxdiagrams.html">syntax diagrams</a> instead of BNF.</li>
<li>Other minor bug fixes</li>
}

chng {2008-09-22 (3.6.3)} {
<li>Fix for a bug in the SELECT DISTINCT logic that was introduced by the
    prior version.</li>

    <font color="red">*** Potentially incompatible change ***</font></li>
<li>The handling of IN and NOT IN operators that contain a NULL on their
    right-hand side expression is brought into compliance with the SQL
    standard and with other SQL database engines.  This is a bug fix,
    but as it has the potential to break legacy applications that depend
    on the older buggy behavior, we mark that as a
    <font color="red">*** Potentially incompatible change ***</font></li>
<li>The result column names generated for compound subqueries have been
    simplified to show only the name of the column of the original table and
    omit the table name.  This makes SQLite operate more like other SQL
    database engines.</li>
<li>Added the [sqlite3_config()] interface for doing run-time configuration
    of the entire SQLite library.</li>
<li>Added the [sqlite3_status()] interface used for querying run-time status
    information about the overall SQLite library and its subsystems.</li>

chng {2007-12-14 (3.5.4)} {
<li>Fix a critical bug in UPDATE or DELETE that occurs when an
OR REPLACE clause or a trigger causes rows in the same table to
be deleted as side effects.  (See ticket #2832.)  The most likely
result of this bug is a segmentation fault, though database
corruption is a possibility.</li>
<li>Bring the processing of ORDER BY into compliance with the
SQL standard for case where a result alias and a table column name
are in conflict.  Correct behavior is to prefer the result alias.
Older versions of SQLite incorrectly picked the table column.
(See ticket #2822.)</li>
<li>The <a href="lang_vacuum.html">VACUUM</a> command preserves
the setting of the
<a href="pragma.html#pragma_legacy_file_format">legacy_file_format pragma</a>.
(Ticket #2804.)</li>
<li>Productize and officially support the group_concat() SQL function.</li>
<li>Better optimization of some IN operator expressions.</li>
<li>Add the ability to change the
<a href="pragma.html#pragma_auto_vacuum">auto_vacuum</a> status of a
database by setting the auto_vaccum pragma and VACUUMing the database.</li>
<li>Prefix search in FTS3 is much more efficient.</li>
<li>Relax the SQL statement length restriction in the CLI so that
the ".dump" output of databases with very large BLOBs and strings can
be played back to recreate the database.</li>
<li>Other small bug fixes and optimizations.</li>

    <a href="34to35.html">34to35.html</a> for details.
    <font color="red">*** Potentially incompatible change ***</font>
<li>The [sqlite3_release_memory()], [sqlite3_soft_heap_limit()],
    and [sqlite3_enable_shared_cache()] interfaces now work cross all
    threads in the process, not just the single thread in which they
    are invoked.
    <font color="red">*** Potentially incompatible change ***</font>
<li>Added the [sqlite3_open_v2()] interface.
<li>Reimplemented the memory allocation subsystem and made it
    replaceable at compile-time.
<li>Created a new mutex subsystem and made it replicable at
    compile-time.
<li>The same database connection may now be used simultaneously by
    separate threads.
}


chng {2007-08-13 (3.4.2)} {
<li>Fix a database corruption bug that might occur if a ROLLBACK command
is executed in <a href="pragma.html#pragma_auto_vacuum">auto-vacuum mode</a>
and a very small [sqlite3_soft_heap_limit] is set.
Ticket #2565.

<li>Add the ability to run a full regression test with a small
[sqlite3_soft_heap_limit].

<li>Fix other minor problems with using small soft heap limits.

<li>Work-around for
[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575 | GCC bug 32575].

<li>Improved error detection of misused aggregate functions.

<li>Improvements to the amalgamation generator script so that all symbols
are prefixed with either SQLITE_PRIVATE or SQLITE_API.
}

chng {2007-06-18 (3.4.0)} {
<li>Fix a bug that can lead to database corruption if an [SQLITE_BUSY] error
    occurs in the middle of an explicit transaction and that transaction
    is later committed.  Ticket #2409.
<li>Fix a bug that can lead to database corruption if autovacuum mode is
    on and a malloc() failure follows a CREATE TABLE or CREATE INDEX statement
    which itself follows a cache overflow inside a transaction.  See
    ticket #2418.
    </li>
<li>Added explicit <a href="limits.html">upper bounds</a> on the sizes and
    quantities of things SQLite can process.  This change might cause
    compatibility problems for
    applications that use SQLite in the extreme, which is why the current
    release is 3.4.0 instead of 3.3.18.</li>
<li>Added support for [sqlite3_blob_open|Incremental BLOB I/O].</li>

<li>When converting BLOB to TEXT, use the text encoding of the main database.
    Ticket #2349</li>
<li>Keep the full precision of integers (if possible) when casting to
    NUMERIC.  Ticket #2364</li>
<li>Fix a bug in the handling of UTF16 codepoint 0xE000</li>
<li>Consider explicit collate clauses when matching WHERE constraints
    to indices in the query optimizer.  Ticket #2391</li>
<li>Fix the query optimizer to correctly handle constant expressions in
    the ON clause of a LEFT JOIN.  Ticket #2403</li>
<li>Fix the query optimizer to handle rowid comparisons to NULL
    correctly.  Ticket #2404</li>
<li>Fix many potential segfaults that could be caused by malicious SQL
    statements.</li>
}

    INSERT INTO <i>table1</i> SELECT * FROM <i>table2</i>
    is faster and reduces fragmentation.  VACUUM uses statements of
    this form and thus runs faster and defragments better.</li>
<li>Performance enhancements through reductions in disk I/O:
<ol type='a'>
  <li>Do not read the last page of an overflow chain when
      deleting the row - just add that page to the freelist.</li>
  <li>Do not store pages being deleted in the
      rollback journal.</li>
  <li>Do not read in the (meaningless) content of
      pages extracted from the freelist.</li>
  <li>Do not flush the page cache (and thus avoiding
      a cache refill) unless another process changes the underlying
      database file.</li>
  <li>Truncate rather than delete the rollback journal when committing
      a transaction in exclusive access mode, or when committing the TEMP
      database.</li>
</ol></li>
<li>Added support for exclusive access mode using
    <a href="pragma.html#pragma_locking_mode">
    "PRAGMA locking_mode=EXCLUSIVE"</a></li>
<li>Use heap space instead of stack space for large buffers in the
    pager - useful on embedded platforms with  stack-space
    limitations.</li>
<li>Add a makefile target "sqlite3.c" that builds an amalgamation containing
    the core SQLite library C code in a single file.</li>
<li>Get the library working correctly when compiled
    with GCC option "-fstrict-aliasing".</li>
<li>Removed the vestigal SQLITE_PROTOCOL error.</li>
<li>Improvements to test coverage, other minor bugs fixed,
    memory leaks plugged,
    code refactored and/or recommended in places for easier reading.</li>
}

chng {2007-02-13 (3.3.13)} {
<li>Add a "fragmentation" measurement in the output of sqlite3_analyzer.</li>
<li>Add the COLLATE operator used to explicitly set the collating sequence
used by an expression.  This feature is considered experimental pending
additional testing.</li>
<li>Allow up to 64 tables in a join - the old limit was 32.</li>
<li>Added two new experimental functions:
<a href="lang_expr.html#randomblobFunc">randomBlob()</a> and
<a href="lang_expr.html#hexFunc">hex()</a>.
Their intended use is to facilitate generating
[http://en.wikipedia.org/wiki/UUID | UUIDs].
</li>
<li>Fix a problem where
<a href="pragma.html#pragma_count_changes">PRAGMA count_changes</a> was
causing incorrect results for updates on tables with triggers</li>
<li>Fix a bug in the ORDER BY clause optimizer for joins where the
left-most table in the join is constrained by a UNIQUE index.</li>

<li>Limit the amount of output that
<a href="pragma.html#pragma_integrity_check">PRAGMA integrity_check</a>
generates.</li>
<li>Minor syntactic changes to support a wider variety of compilers.</li>
}

chng {2007-01-22 (3.3.11)} {
<li>Fix another bug in the implementation of the new
<a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> API.
We'll get it right eventually...</li>
<li>Fix a bug in the IS NULL optimization that was added in version 3.3.9 -
the bug was causing incorrect results on certain LEFT JOINs that included
in the WHERE clause an IS NULL constraint for the right table of the
LEFT JOIN.</li>
<li>Make AreFileApisANSI() a no-op macro in WinCE since WinCE does not
support this function.</li>
}

chng {2007-01-09 (3.3.10)} {
<li>Fix bugs in the implementation of the new
<a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> API
that can lead to segfaults.</li>
<li>Fix 1-second round-off errors in the
strftime() function</li>
<li>Enhance the Windows OS layer to provide detailed error codes</li>
<li>Work around a win2k problem so that SQLite can use single-character
database file names</li>
<li>The
<a href="pragma.html#pragma_user_version">user_version</a> and
<a href="pragma.html#pragma_schema_version">schema_version</a> pragmas
correctly set their column names in the result set</li>
<li>Documentation updates</li>
}

chng {2007-01-04 (3.3.9)} {
<li>Fix bugs in pager.c that could lead to database corruption if two
processes both try to recover a hot journal at the same instant</li>

<li>Added experimental API:  sqlite3_auto_extension()</li>
<li>Various minor bug fixes</li>
}

chng {2006-08-12 (3.3.7)} {
<li>Added support for virtual tables (beta)</li>
<li>Added support for dynamically loaded extensions (beta)</li>
<li>The
<a href="c3ref/interrupt.html">sqlite3_interrupt()</a>
routine can be called for a different thread</li>
<li>Added the <a href="lang_expr.html#match">MATCH</a> operator.</li>
<li>The default file format is now 1.
}

chng {2006-06-06 (3.3.6)} {
<li>Plays better with virus scanners on Windows</li>
<li>Faster :memory: databases</li>
<li>Fix an obscure segfault in UTF-8 to UTF-16 conversions</li>
<li>Added driver for OS/2</li>

<li>Optional READ UNCOMMITTED isolation (instead of the default
isolation level of SERIALIZABLE) and table level locking when
database connections share a common cache.</li>
}

chng {2005-12-19 (3.2.8)} {
<li>Fix an obscure bug that can cause database corruption under the
following unusual circumstances: A large INSERT or UPDATE statement which
is part of an even larger transaction fails due to a uniqueness constraint
but the containing transaction commits.</li>
}

chng {2005-12-19 (2.8.17)} {
<li>Fix an obscure bug that can cause database corruption under the
following unusual circumstances: A large INSERT or UPDATE statement which
is part of an even larger transaction fails due to a uniqueness contraint
but the containing transaction commits.</li>
}

chng {2005-09-24 (3.2.7)} {
<li>GROUP BY now considers NULLs to be equal again, as it should
</li>

chng {2005-03-11 (3.1.4)} {
<li>Fix a bug in autovacuum that could cause database corruption if
a CREATE UNIQUE INDEX fails because of a constraint violation.
This problem only occurs if the new autovacuum feature introduced in
version 3.1 is turned on.</li>
<li>The F_FULLSYNC ioctl (currently only supported on Mac OS X) is disabled
if the synchronous pragma is set to something other than "full".</li>
<li>Add additional forward compatibility to the future version 3.2 database
file format.</li>
<li>Fix a bug in WHERE clauses of the form (rowid<'2')</li>
<li>New [omitfeatures | SQLITE_OMIT_...] compile-time options added</li>
<li>Updates to the man page</li>
<li>Remove the use of strcasecmp() from the shell</li>
<li>Windows DLL exports symbols Tclsqlite_Init and Sqlite_Init</li>
}

    off of the stack, in order to play better on machines with limited
    stack space.</li>
<li>Fixed naming conflicts so that versions 2.8 and 3.0 can be
    linked and used together in the same ANSI-C source file.</li>
<li>New interface: sqlite3_bind_parameter_index()</li>
<li>Add support for wildcard parameters of the form: "?nnn"</li>
<li>Fix problems found on 64-bit systems.</li>
<li>Removed encode.c file (containing unused routines) from the
    version 3.0 source tree.</li>
<li>The sqlite3_trace() callbacks occur before each statement
    is executed, not when the statement is compiled.</li>
<li>Makefile updates and miscellaneous bug fixes.</li>
}

chng {2004-09-02 (3.0.6 beta)} {

<li><a href="version3.html">More information</a>.
}

chng {2004-06-09 (2.8.14)} {
<li>Fix the min() and max() optimizer so that it works when the FROM
    clause consists of a subquery.</li>
<li>Ignore extra whitespace at the end of "." commands in the shell.</li>
<li>Bundle sqlite_encode_binary() and sqlite_decode_binary() with the
    library.</li>
<li>The TEMP_STORE and DEFAULT_TEMP_STORE pragmas now work.</li>
<li>Code changes to compile cleanly using OpenWatcom.</li>
<li>Fix VDBE stack overflow problems with INSTEAD OF triggers and
    NULLs in IN operators.</li>
<li>Add the global variable sqlite_temp_directory which if set defines the
    directory in which temporary files are stored.</li>

<li>Fix a bug in how the IN operator handles NULLs in subqueries.  The bug
    was introduced by the previous release.</li>
}

chng {2004-01-14 (2.8.10)} {
<li>Fix a potential database corruption problem on Unix caused by the fact
    that all POSIX advisory locks are cleared whenever you close() a file.
    The work around it to embargo all close() calls while locks are
    outstanding.</li>
<li>Performance enhancements on some corner cases of COUNT(*).</li>
<li>Make sure the in-memory backend response sanely if malloc() fails.</li>
<li>Allow sqlite_exec() to be called from within user-defined SQL
    functions.</li>
<li>Improved accuracy of floating-point conversions using "long double".</li>
<li>Bug fixes in the experimental date/time functions.</li>

chng {2003-07-22 (2.8.5)} {
<li>Make LIMIT work on a compound SELECT statement.</li>
<li>LIMIT 0 now shows no rows.  Use LIMIT -1 to see all rows.</li>
<li>Correctly handle comparisons between an INTEGER PRIMARY KEY and
    a floating point number.</li>
<li>Fix several important bugs in the new ATTACH and DETACH commands.</li>
<li>Updated the <a href="nulls.html">NULL-handling document</a>.</li>
<li>Allow NULL arguments in sqlite_compile() and sqlite_step().</li>
<li>Many minor bug fixes</li>
}

chng {2003-06-29 (2.8.4)} {
<li>Enhanced the "PRAGMA integrity_check" command to verify indices.</li>
<li>Added authorization hooks for the new ATTACH and DETACH commands.</li>

chng {2003-05-17 (2.8.2)} {
<li>Fix a problem that will corrupt the database file if you drop a
    table from the main database that has a TEMP index.</li>
}

chng {2003-05-17 (2.8.1)} {
<li>Reactivated the VACUUM command that reclaims unused disk space in
    a database file.</li>
<li>Added the ATTACH and DETACH commands to allow interacting with multiple
    database files at the same time.</li>
<li>Added support for TEMP triggers and indices.</li>
<li>Added support for in-memory databases.</li>
<li>Removed the experimental sqlite_open_aux_file().  Its function is
    subsumed in the new ATTACH command.</li>

chng {2002-12-17 (2.7.4)} {
<li>Database files can now grow to be up to 2&#94;41 bytes.  The old limit
    was 2&#94;31 bytes.</li>
<li>The optimizer will now scan tables in the reverse if doing so will
    satisfy an ORDER BY ... DESC clause.</li>
<li>The full pathname of the database file is now remembered even if
    a relative path is passed into sqlite_open().  This allows
    the library to continue operating correctly after a chdir().</li>
<li>Speed improvements in the VDBE.</li>
<li>Lots of little bug fixes.</li>
}

chng {2002-10-31 (2.7.3)} {
<li>Various compiler compatibility fixes.</li>

<li>Added support for user-defined functions implemented in C.</li>
<li>Added support for new functions: <b>coalesce()</b>, <b>lower()</b>,
    <b>upper()</b>, and <b>random()</b>
<li>Added support for VIEWs.</li>
<li>Added the subquery flattening optimizer.</li>
<li>Modified the B-Tree and Pager modules so that disk pages that do not
    contain real data (free pages) are not journaled and are not
    written from memory back to the disk when they change.  This does not
    impact database integrity, since the
    pages contain no real data, but it does make large INSERT operations
    about 2.5 times faster and large DELETEs about 5 times faster.</li>
<li>Made the CACHE_SIZE pragma persistent</li>
<li>Added the SYNCHRONOUS pragma</li>
<li>Fixed a bug that was causing updates to fail inside of transactions when
    the database contained a temporary table.</li>

    all correct (as far as is known) so everything should work OK if you
    compile with -DNDEBUG=1.  When asserts are not disabled, there
    could be a fault.</li>
}

chng {2002-02-13 (2.3.1)} {
<li>Bug fix: An assertion was failing if "PRAGMA full_column_names=ON;" was
    set and you did a query that used a rowid, like this:
    "SELECT rowid, * FROM ...".</li>
}

chng {2002-02-03 (2.3.0)} {
<li>Fix a serious bug in the INSERT command which was causing data to go
    into the wrong columns if the data source was a SELECT and the INSERT
    clauses specified its columns in some order other than the default.</li>
<li>Added the ability to resolve constraint conflicts is ways other than
    an abort and rollback.  See the documentation on the "ON CONFLICT"
    clause for details.</li>
<li>Temporary files are now automatically deleted by the operating system
    when closed.  There are no more dangling temporary files on a program
    crash.  (If the OS crashes, fsck will delete the file after reboot
    under Unix.  I do not know what happens under Windows.)</li>
<li>NOT NULL constraints are honored.</li>
<li>The COPY command puts NULLs in columns whose data is '\N'.</li>
<li>In the COPY command, backslash can now be used to escape a newline.</li>
<li>Added the SANITY_CHECK pragma.</li>
}

    within a single transaction was causing a coredump.</li>
<li>Makefile updates from A. Rottmann</li>
}

chng {2001-12-22 (2.2.0)} {
<li>Columns of type INTEGER PRIMARY KEY are actually used as the primary
    key in underlying B-Tree representation of the table.</li>
<li>Several obscure, unrelated bugs were found and fixed while
    implemented the integer primary key change of the previous bullet.</li>
<li>Added the ability to specify "*" as part of a larger column list in
    the result section of a SELECT statement.  For example:
    <nobr>"<b>SELECT rowid, * FROM table1;</b>"</nobr>.</li>
<li>Updates to comments and documentation.</li>
}

<li>Fix the locking mechanism yet again to prevent
    <b>sqlite_exec()</b> from returning SQLITE_PROTOCOL
    unnecessarily.  This time the bug was a race condition in
    the locking code.  This change affects both POSIX and Windows users.</li>
}

chng {2001-12-06 (2.1.5)} {
<li>Fix for another problem (unrelated to the one fixed in 2.1.4)
    that sometimes causes <b>sqlite_exec()</b> to return SQLITE_PROTOCOL
    unnecessarily.  This time the bug was
    in the POSIX locking code and should not effect Windows users.</li>
}

chng {2001-12-05 (2.1.4)} {
<li>Sometimes <b>sqlite_exec()</b> would return SQLITE_PROTOCOL when it
    should have returned SQLITE_BUSY.</li>
<li>The fix to the previous bug uncovered a deadlock which was also
    fixed.</li>
<li>Add the ability to put a single .command in the second argument
    of the sqlite shell</li>
<li>Updates to the FAQ</li>
}

chng {2001-11-24 (2.1.3)} {
<li>Fix the behavior of comparison operators
    (ex: "<b>&lt;</b>", "<b>==</b>", etc.)
    so that they are consistent with the order of entries in an index.</li>
<li>Correct handling of integers in SQL expressions that are larger than
    what can be represented by the machine integer.</li>
}

chng {2001-11-23 (2.1.2)} {
<li>Changes to support 64-bit architectures.</li>
<li>Fix a bug in the locking protocol.</li>
<li>Fix a bug that could (rarely) cause the database to become
    unreadable after a DROP TABLE due to corruption to the SQLITE_MASTER
    table.</li>
<li>Change the code so that version 2.1.1 databases that were rendered
    unreadable by the above bug can be read by this version of
    the library even though the SQLITE_MASTER table is (slightly)
    corrupted.</li>
}

chng {2001-11-13 (2.1.1)} {
<li>Bug fix: Sometimes arbitrary strings were passed to the callback

    code.
    </li>
}

chng {2001-03-14 (1.0.24)} {
<li>Fix a bug which was causing
    the UPDATE command to fail on systems where "malloc(0)" returns
    NULL.  The problem does not appear on Windows, Linux, or HPUX but does
    cause the library to fail on QNX.
    </li>
}

chng {2001-02-20 (1.0.23)} {
<li>An unrelated (and minor) bug from Mark Muranwski fixed.  The algorithm
    for figuring out where to put temporary files for a "memory:" database

<li>Break out the GDBM driver into a separate file in anticipation
    to added new drivers.</li>
<li>Allow the name of a database to be prefixed by the driver type.
    For now, the only driver type is "gdbm:".</li>
}

chng {2000-10-17 (1.0.12)} {
<li>Fixed an off-by-one error that was causing a coredump in
    the '%q' format directive of the new
    <b>sqlite_..._printf()</b> routines.</li>
<li>Added the <b>sqlite_interrupt()</b> interface.</li>
<li>In the shell, <b>sqlite_interrupt()</b> is invoked when the
    user presses Control-C</li>
<li>Fixed some instances where <b>sqlite_exec()</b> was
    returning the wrong error code.</li>
}

chng {2000-10-11 (1.0.10)} {
<li>Added notes on how to compile for Windows95/98.</li>
<li>Removed a few variables that were not being used.  Etc.</li>
}

chng {2000-10-09 (1.0.9)} {
<li>Added the <b>sqlite_..._printf()</b> interface routines.</li>
<li>Modified the <b>sqlite</b> shell program to use the new interface
    routines.</li>
<li>Modified the <b>sqlite</b> shell program to print the schema for
    the built-in SQLITE_MASTER table, if explicitly requested.</li>
}

chng {2000-09-30 (1.0.8)} {
<li>Begin writing documentation on the TCL interface.</li>

}

chng {2000-07-29} {
<li>Better labels on column names of the result.</li>
}

chng {2000-07-28} {
<li>Added the <b>sqlite_busy_handler()</b>
    and <b>sqlite_busy_timeout()</b> interface.</li>
}

chng {2000-06-23} {
<li>Begin writing the <a href="vdbe.html">VDBE tutorial</a>.</li>
}

chng {2000-06-03} {
<li>Added support for default values on columns of a table.</li>
<li>Improved test coverage.  Fixed a few obscure bugs found by the
improved tests.</li>
}

chng {2000-06-02} {
<li>All database files to be modified by an UPDATE, INSERT or DELETE are
now locked before any changes are made to any files.
This makes it safe (I think) to access
the same database simultaneously from multiple processes.</li>
<li>The code appears stable so we are now calling it "beta".</li>
}

chng {2000-06-01} {
<li>Better support for file locking so that two or more processes
(or threads)
can access the same database simultaneously.  More work needed in
this area, though.</li>
}

chng {2000-05-31} {
<li>Added support for aggregate functions (Ex: <b>COUNT(*)</b>, <b>MIN(...)</b>)
to the SELECT statement.</li>
<li>Added support for <B>SELECT DISTINCT ...</B></li>
}

chng {2000-05-30} {
<li>Added the <b>LIKE</b> operator.</li>
<li>Added a <b>GLOB</b> operator: similar to <B>LIKE</B>
but it uses Unix shell globbing wildcards instead of the '%'
and '_' wildcards of SQL.</li>
<li>Added the <B>COPY</b> command patterned after
[http://www.postgresql.org/ | PostgreSQL] so that SQLite
can now read the output of the <b>pg_dump</b> database dump utility
of PostgreSQL.</li>
<li>Added a <B>VACUUM</B> command that calls the
<b>gdbm_reorganize()</b> function on the underlying database
files.</li>
<li>And many, many bug fixes...</li>
}

chng {2000-05-29} {
<li>Initial Public Release of Alpha code</li>

        hd_resolve "<p><b>Bug fixes backported into patch release $vers ($date):</b></p>\n"
        hd_resolve "$d2\n"
      }
    }
    hd_resolve "</ol></p>\n"
    hd_resolve {
      <p>A [complete list of SQLite releases]
      in a single page and a [chronology] are both also available.
      A detailed history of every
      check-in is available at
      <a href="http://www.sqlite.org/src/timeline">
      SQLite version control site</a>.</p>
    }
    hd_close_aux
    hd_enable_main 1

set nRelease 0
set mxDate {1970-01-01}
set mnDate {2999-12-31}
set jsonSep \[
set jsonChronology [open chronology.json wb]
puts -nonewline $jsonChronology "chronology = "
# Iterate over the chronology provided by a proc in ./pages/chronology.tcl .
set then [db one {SELECT julianday('2000-08-16')}] ;# for sorting
foreach {udvv} [chronology_info] {
  foreach {uuid date vers vnum} $udvv break;
  hd_puts "<tr>"
  if {[regexp {\d\d\d\d-\d\d-\d\d} $date]} {
    set url https://www.sqlite.org/src/timeline
    append url ?c=$uuid&y=ci
    set jJulianDay [db one {SELECT julianday($date)}]
    set sortKey [format "%05d" [expr {int($jJulianDay - $then)}]]
    hd_puts "<td width='100' align='center' data-sortkey='$sortKey'>"
    hd_puts "<a href='$url'>$date</a></td>\n"
    if {$date>$mxDate} {set mxDate $date}
    if {$date<$mnDate} {set mnDate $date}

  } else {
    # Say pending release(s) date is a month from today in chronology.json .
    set jJulianDay [expr [db one {SELECT julianday()}] + 30]
    hd_puts "<td width='100' align='center' data-sortkey='99999'>"

    hd_puts "$date</td>\n"
  }
  incr nRelease
  hd_puts "<td width='100' align='center' data-sortkey='$vnum'>"
  if {[info exists "::glink(version $vers)"]} {
    hd_resolve "\[version $vers|$vers\]</td></tr>\n"
    glref_add "version $vers"
  } else {

  }
  this.sortNumeric = function(a,b) {
    var i = thisObject.sortIndex;
    aa = parseFloat(a.cells[i].textContent);
    if (isNaN(aa)) aa = 0;
    bb = parseFloat(b.cells[i].textContent);
    if (isNaN(bb)) bb = 0;
    if(aa<bb) return -1;
    if(aa>bb) return +1;
    return a.rowIndex-b.rowIndex;
  }
  this.sortKey = function(a,b) {
    var i = thisObject.sortIndex;
    aa = a.cells[i].getAttribute("data-sortkey");
    bb = b.cells[i].getAttribute("data-sortkey");
    if(aa<bb) return -1;
    if(aa==bb) return a.rowIndex-b.rowIndex;

    hdrcell.onclick = function () {
      this.sTable.sort(this);
      return false;
    }
  }
  this.setHdrIcons()
}
var t = new SortableTable(document.getElementById("chrontab"),"nK",1);
</script>
}</tcl>
<p>
<tcl>
set nDay [db eval {SELECT julianday($mxDate)-julianday($mnDate)}]
hd_putsnl "<i>$nRelease releases"
hd_putsnl "over [format %.1f [expr {$nDay/365.24}]] years.</i>"
</tcl>

# Data returned by below proc is used by wrap.tcl for its dateof:?
# tag substitution and pages/chronology.in for its machinations.

# Return list of lists, each a 4-tuple: uuid date vers vnum
proc chronology_info {} {
  set rv [list]
  foreach line [split {
xxxxxxxxxx|pending|Version 3.41.0
df5c253c0b|2022-12-28|Version 3.40.1
89c459e766|2022-11-16|Version 3.40.0
a29f994989|2022-09-29|Version 3.39.4
4635f4a69c|2022-09-05|Version 3.39.3
698edb7753|2022-07-21|Version 3.39.2
7c16541a0e|2022-07-13|Version 3.39.1
14e166f40d|2022-06-25|Version 3.39.0
78d9c993d4|2022-05-06|Version 3.38.5

<li><p><b>[sqlite3_open()]</b> &rarr;
Open a connection to a new or existing SQLite database.
The constructor for [sqlite3].

<li><p><b>[sqlite3_prepare()]</b> &rarr;
Compile SQL text into
byte-code that will do the work of querying or updating the database.
The constructor for [sqlite3_stmt].

<li><p><b>[sqlite3_bind_int|sqlite3_bind()]</b> &rarr;
Store application data into
[parameters] of the original SQL.

</p>

<p>
  A separate document, [capi3ref | The SQLite C/C++ Interface],
  provides detailed
  specifications for all C/C++ APIs for SQLite.  Once
  the reader
  understands the basic principles of operation for SQLite,
  [capi3ref | that document] should be used as a reference
  guide.  This article is intended as introduction only and is neither a
  complete nor authoritative reference for the SQLite API.
</p>

<h1>Core Objects And Interfaces</h1>

  For example, the list above shows a single routine
  named [sqlite3_open()] when in fact there are three separate routines
  that accomplish the same thing in slightly different ways:
  [sqlite3_open()], [sqlite3_open16()] and [sqlite3_open_v2()].
  The list mentions [sqlite3_column_int | sqlite3_column()]
  when in fact no such routine exists.
  The "sqlite3_column()" shown in the list is a placeholder for
  an entire family of routines that extract column
  data in various datatypes.
</p>

<p>
  Here is a summary of what the core interfaces do:
</p>

<ul>

<li><p><b>[sqlite3_open()]</b>
<p>
  This routine
  opens a connection to an SQLite database file and returns a
  [database connection] object.  This is often the first SQLite API
  call that an application makes and is a prerequisite for most other
  SQLite APIs.  Many SQLite interfaces require a pointer to
  the [database connection] object as their first parameter and can
  be thought of as methods on the [database connection] object.
  This routine is the constructor for the [database connection] object.

<li><p><b>[sqlite3_column_int | sqlite3_column()]</b>
<p>
  This routine returns a single column from the current row of a result
  set for a [prepared statement] that is being evaluated by [sqlite3_step()].
  Each time [sqlite3_step()] stops with a new result set row, this routine
  can be called multiple times to find the values of all columns in that row.

  <p>As noted above, there really is no such thing as a "sqlite3_column()"
  function in the SQLite API.  Instead, what we here call "sqlite3_column()"
  is a place-holder for an entire family of functions that return
  a value from the result set in various data types.  There are also routines
  in this family that return the size of the result (if it is a string or
  BLOB) and the number of columns in the result set.

  <p><ul>
    <li> [sqlite3_column_blob()] </li>
    <li> [sqlite3_column_bytes()] </li>
    <li> [sqlite3_column_bytes16()] </li>
    <li> [sqlite3_column_count()] </li>
    <li> [sqlite3_column_double()] </li>

  To run an SQL statement, the application follows these steps:
</p>

<p><ol>
  <li> Create a [prepared statement] using [sqlite3_prepare()]. </li>
  <li> Evaluate the [prepared statement] by calling [sqlite3_step()] one
       or more times. </li>
  <li> For queries, extract results by calling
       [sqlite3_column_int | sqlite3_column()] in between
       two calls to [sqlite3_step()]. </li>
  <li> Destroy the [prepared statement] using [sqlite3_finalize()]. </li>
</ol></p>

<p>
  The foregoing is all one really needs to know in order to use SQLite

  this, SQLite allows SQL statements to contain [parameter | parameters]
  which are "bound" to values prior to being evaluated.  These values can
  later be changed and the same [prepared statement] can be evaluated
  a second time using the new values.
</p>

<p>
  SQLite allows a [parameter] wherever a string literal,
  blob literal, numeric constant, or NULL is allowed
  in queries or data modification statements. (DQL or DML)
  (Parameters may not be used for column or table names,
  or as values for constraints or default values. (DDL))
  A [parameter] takes one of the following forms:
</p>

<p><ul>
  <li> <b>?</b> </li>
  <li> <b>?</b><i>NNN</i> </li>
  <li> <b>:</b><i>AAA</i> </li>

<ul>
<li>Adjust how SQLite does [memory allocation], including setting up
    alternative memory allocators appropriate for safety-critical
    real-time embedded systems and application-defined memory allocators.
<li>Set up a process-wide [error log].
<li>Specify an application-defined page cache.
<li>Adjust the use of mutexes so that they are appropriate for various
    [threading mode | threading models], or substitute an
    application-defined mutex system.
</ul>
<p>
  After process-wide configuration is complete and [database connections]
  have been created, individual database connections can be configured using
  calls to [sqlite3_limit()] and [sqlite3_db_config()].

<h1>Extending SQLite</h1>

  [collating sequences] for sorting text.
  The [sqlite3_create_module()] interface is used to register new
  [virtual table] implementations.
  The [sqlite3_vfs_register()] interface creates new [VFSes].
</p>

<p>
  The [sqlite3_create_function()] interface creates new SQL functions -
  either scalar or aggregate.  The new function implementation typically
  makes use of the following additional interfaces:
</p>

<p><ul>
  <li> [sqlite3_aggregate_context()] </li>
  <li> [sqlite3_result_int | sqlite3_result()] </li>
  <li> [sqlite3_user_data()] </li>
  <li> [sqlite3_value_int | sqlite3_value()] </li>
</ul></p>

<p>
  All of the built-in SQL functions of SQLite are created using exactly
  these same interfaces.  Refer to the SQLite source code, and in particular
  the
  [http://www.sqlite.org/src/doc/trunk/src/date.c | date.c] and
  [http://www.sqlite.org/src/doc/trunk/src/func.c | func.c] source files
  for examples.
</p>

<p>
  Shared libraries or DLLs can be used as [loadable extensions] to SQLite.

<h1>Other Interfaces</h1>

<p>
  This article only mentions the most important and most commonly
  used SQLite interfaces.
  The SQLite library includes many other APIs implementing useful
  features that are not described here.
  A [capi3ref_funclist | complete list of functions] that form the SQLite
  application programming interface is found at the
  [capi3ref | C/C++ Interface Specification].
  Refer to that document for complete and authoritative information about
  all SQLite interfaces.
</p>

  SQLITE_ENABLE_SORTER_REFERENCES option will help or hurt performance,
  it is disabled by default at this time (2018-05-04).  It might be enabled
  by default in some future release, depending on what is learned about its
  impact on performance.
}

COMPILE_OPTION {SQLITE_ENABLE_STMT_SCANSTATUS} {
  This option enables the [sqlite3_stmt_scanstatus()] and
  [sqlite3_stmt_scanstatus_v2()] interfaces.  Those
  interfaces are normally omitted from the build
  because they imposes a performance penalty, even on statements that
  do not use the feature.
}

COMPILE_OPTION {SQLITE_ENABLE_STMTVTAB} {
  This compile-time option enables the [SQLITE_STMT virtual table] logic.
}

<p>
SQLite [https://sqlite.org/src|source code]
is in the [public-domain] and is free to 
everyone to use for any purpose.

<h3>Latest Release</h3>
<a href="releaselog/3_41_0.html">Version 3.41.0</a> ([dateof:3.41.0]).
<a class="button" href="download.html">Download</a>
<a class="button" href="chronology.html">Prior Releases</a>

<div class="mobileonly">
<h3>Common Links</h3>
<tcl>common_links</tcl>
</div>

<p>^The unary operator [Operator +] is a no-op.  ^It can be applied
to strings, numbers, blobs or NULL and it always returns a result
with the same value as the operand.</p>"</tcl>

<p>Note that there are two variations of the equals and not equals
operators.  ^Equals can be either


<tcl>hd_puts "[Operator =] or [Operator ==].
^The not-equal operator can be either
[Operator !=] or [Operator {&lt;&gt;}].
^The [Operator ||] operator is \"concatenate\" - it joins together
the two strings of its operands.
^The [Operator {-&gt;}] and [Operator {-&gt;&gt;}] operators are \"extract\";
they extract the RHS component from the LHS."</tcl>
For an example, see
[{the -> and ->> operators}|JSON subcomponent extraction].</p>

<p>
<tcl>hd_resolve "
^The [Operator %] operator \[cast|casts\] both of its operands to type
INTEGER and then computes the remainder after dividing the left integer
by the right integer. The other arithmetic operators perform integer
arithmetic if both operands are integers and no overflow would result,
or floating point arithmetic, per IEEE Standard 754, if either operand
is a real value or integer arithmetic would produce an overflow.
Integer divide yields an integer result, truncated toward zero.
</p>

<p>^The result of any binary operator is either a numeric value or
NULL, except for the [Operator ||] concatenation operator,
and the [Operator {-&gt;}] and [Operator {-&gt;&gt;}] extract operators
which evaluate to either NULL or a text value.</p>

<p>All operators generally evaluate to NULL when any operand is NULL,
with specific exceptions as stated below. This is in accordance with
the SQL92 standard.</p>

<p>
^(If a numeric literal has a decimal point or an exponentiation
clause or if it is less than -9223372036854775808 or
greater than 9223372036854775807, then it is a floating point literal.
Otherwise is it is an  integer literal.)^
^The "E" character that begins the exponentiation
clause of a floating point literal can be either upper or lower case.
^(The "." character is always used
as the decimal point even if the locale setting specifies "," for
this role - the use of "," for the decimal point would result in
syntactic ambiguity.)^

<tcl>hd_fragment hexint {hexadecimal integer literals} {hexadecimal integers}</tcl>
<p>^Hexadecimal integer literals follow the C-language notation of
"0x" or "0X" followed by hexadecimal digits.

^A literal value can also be the token "NULL".
</p>

<tcl>hd_fragment varparam parameter parameters {bound parameter} {bound parameters}</tcl>
<h1>Parameters</h1>
<p>
A "variable" or "parameter" token
specifies a placeholder in the expression for a
value that is filled in at runtime using the
[sqlite3_bind_blob() | sqlite3_bind()] family of C/C++ interfaces.
Parameters can take several forms:
</p>

<blockquote>
<table>

engines.  But because it is easy to miscount the question marks, the
use of this parameter format is discouraged.  Programmers are encouraged
to use one of the symbolic formats below or the ?NNN format above instead.
</td>
</tr>
<tr>
<td align="right" valign="top"><b>:</b><i>AAAA</i></td><td width="20"></td>
<td>^A colon followed by an identifier name holds a spot for a
[sqlite3_bind_parameter_name|named parameter] with the name :AAAA.
^(Named parameters are also numbered. The number assigned is one greater than
the largest parameter number already assigned.)^ ^If this means the parameter
would be assigned a number greater than [SQLITE_MAX_VARIABLE_NUMBER], it is
an error. To avoid confusion, it is best to avoid mixing named and numbered
parameters.</td>
</tr>
<tr>
<td align="right" valign="top"><b>@</b><i>AAAA</i></td><td width="20"></td>
<td>^An "at" sign works exactly like a colon, except that the name of
the parameter created is @AAAA.</td>
</tr>
<tr>
<td align="right" valign="top"><b>$</b><i>AAAA</i></td><td width="20"></td>
<td>^A dollar-sign followed by an identifier name also holds a spot for a named
parameter with the name $AAAA.  ^(The identifier name in this case can include
one or more occurrences of "::" and a suffix enclosed in "(...)" containing
any text at all.)^  This syntax is the form of a variable name in the
[http://www.tcl-lang.org/ | Tcl programming language].  The presence
of this syntax results from the fact that SQLite is really a
[Tcl extension] that has escaped into the wild.</td>
</tr>
</table>
</blockquote>

<p>^Parameters that are not assigned values using
[sqlite3_bind_blob() | sqlite3_bind()] are treated

<p>^The LIKE operator can be made case sensitive using the
[case_sensitive_like pragma].</p>

<tcl>hd_fragment glob GLOB</tcl>
<p>^The GLOB operator is similar to LIKE but uses the Unix
file globbing syntax for its wildcards.  ^Also, GLOB is case
sensitive, unlike LIKE.  ^Both GLOB and LIKE may be preceded by
the NOT keyword to invert the sense of the test.  ^The infix GLOB
operator is implemented by calling the function
[glob(<i>Y</i>,<i>X</i>)] and can be modified by overriding
that function.</p>

<tcl>hd_fragment regexp REGEXP</tcl>
<p>^The REGEXP operator is a special syntax for the regexp()
user function.  ^No regexp() user function is defined by default

raises an exception and is not really useful for anything.
^But extensions can override the match() function with more
helpful logic.</p>

<tcl>hd_fragment extract extract</tcl>
<p>^The extract operators act as a special syntax for functions
"-&gt;"() and "-&gt;&gt;"(). ^Default implementations for these functions
perform [{the -> and ->> operators}|JSON subcomponent extraction],
but extensions can override them for other purposes.</p>

<tcl>hd_fragment between BETWEEN</tcl>
<h1>The BETWEEN operator</h1>
<p>^(The BETWEEN operator is logically equivalent to a pair of comparisons.
"<i>x</i> <b>BETWEEN</b> <i>y</i> <b>AND</b> <i>z</i>" is
equivalent to
"<i>x</i><b>&gt;=</b><i>y</i> <b>AND</b> <i>x</i><b>&lt;=</b><i>z</i>" except
that with BETWEEN, the <i>x</i> expression is only evaluated once.)^

<tcl>hd_fragment case {CASE expression}</tcl>
<h1>The CASE expression</h1>
<p>A CASE expression serves a role similar to IF-THEN-ELSE in other
programming languages.

<p>The optional expression that occurs in between the CASE keyword and the
first WHEN keyword is called the "base" expression. ^There are two
fundamental forms
of the CASE expression: those with a base expression and those without.

<p>^In a CASE without a base expression, each WHEN expression is evaluated
and the result treated as a boolean, starting with the leftmost and continuing
to the right. ^The result of the CASE expression is the evaluation of the THEN
expression that corresponds to the first WHEN expression that evaluates to
true. ^Or, if none of the WHEN expressions evaluate to true, the result of
evaluating the ELSE expression, if any. ^If there is no ELSE expression and
none of the WHEN expressions are true, then the overall result is NULL.

<p>^A NULL result is considered untrue when evaluating WHEN terms.

<p>^In a CASE with a base expression, the base expression is evaluated just
once and the result is compared against the evaluation of each WHEN
expression from left to right. ^The result of the CASE expression is the
evaluation of the THEN expression that corresponds to the first WHEN
expression for which the comparison is true. ^Or, if none of the WHEN
expressions evaluate to a value equal to the base expression, the result
of evaluating the ELSE expression, if any. ^If there is no ELSE expression and
none of the WHEN expressions produce a result equal to the base expression,
the overall result is NULL.

<p>^When comparing a base expression against a WHEN expression, the same
collating sequence, affinity, and NULL-handling rules apply as if the
base expression and WHEN expression are respectively the left- and
right-hand operands of an <big><b>=</b></big> operator.</p>

<p>^If the base
expression is NULL then the result of the CASE is always the result
of evaluating the ELSE expression if it exists, or NULL if it does not.

<p>^Both forms of the CASE expression use lazy, or short-circuit,
evaluation.

<p>^(The only difference between the following two CASE expressions is that
the <i>x</i> expression is evaluated exactly once in the first example but
might be evaluated multiple times in the second:

<ul><pre>
<li>CASE x WHEN w1 THEN r1 WHEN w2 THEN r2 ELSE r3 END
<li>CASE WHEN x=w1 THEN r1 WHEN x=w2 THEN r2 ELSE r3 END
</pre></ul>)^

the [row value] of the left operand.  ^The subquery on the
right of an IN or NOT IN operator must be a scalar subquery if the left
expression is not a [row value] expression.
^If the right operand of an IN or NOT IN operator is a list of values,
each of those values must be scalars and the left expression must also
be a scalar.
^The right-hand side of an IN or NOT IN operator can be a
table <i>name</i> or [table-valued function] <i>name</i> in which
case the right-hand side is understood to be subquery of
the form "(SELECT * FROM <i>name</i>)".
^When the right operand is an empty set, the result of IN is false and the
result of NOT IN is true, regardless of the left operand and even if the
left operand is NULL.
<p>^(The result of an IN or NOT IN operator is determined by the following
matrix:

<h1>Table Column Names</h1>

<p>^A column name can be any of the names defined in the [CREATE TABLE]
statement or one of the following special identifiers: "<b>ROWID</b>",
"<b>OID</b>", or "<b>_ROWID_</b>".
^The three special identifiers describe the
unique integer key (the [rowid]) associated with every
row of every table and so are not available on [WITHOUT ROWID] tables.
^The special identifiers only refer to the row key if the [CREATE TABLE]
statement does not define a real column with the same name.
^The rowid can be used anywhere a regular
column can be used.</p>

<tcl>hd_fragment exists_op {EXISTS operator} {NOT EXISTS operator}</tcl>
<h1>The EXISTS operator</h1>

<p>^The EXISTS operator always evaluates to one of the integer values 0
and 1. ^If executing the SELECT statement specified as the right-hand
operand of the EXISTS operator would return one or more rows, then the
EXISTS operator evaluates to 1. ^If executing the SELECT would return
no rows at all, then the EXISTS operator evaluates to 0.

<p>^The number of columns in each row returned by the SELECT statement
(if any) and the specific values returned have no effect on the results
of the EXISTS operator. ^In particular, rows containing NULL values are
not handled any differently from rows without NULL values.

<tcl>hd_fragment subq {Subqueries}</tcl>

^A subquery that returns two or more columns is a [row value]
subquery and can only be used as an operand of a comparison operator or as
the value in an UPDATE SET clause whose column name list has the same size.

<tcl>hd_fragment cosub {correlated subqueries}</tcl>
<h1>Correlated Subqueries</h1>

<p>^A [SELECT] statement used as either a scalar subquery or as the
right-hand operand of an IN, NOT IN or EXISTS expression may contain
references to columns in the outer query. Such a subquery is known as
a correlated subquery. ^A correlated subquery is reevaluated each time
its result is required. ^An uncorrelated subquery is evaluated only once
and the result reused as necessary.

<tcl>hd_fragment castexpr {CAST expression} {CAST} {cast} {CAST operator}</tcl>
<h1>CAST expressions</h1>

<p>A CAST expression of the form "CAST(<i>expr</i> AS <i>type-name</i>)"
is used to convert the value of <i>expr</i> to
a different [storage class] specified by <yyterm>type-name</yyterm>.
^A CAST conversion is similar to the conversion that takes
place when a [column affinity] is applied to a value except that with
the CAST operator the conversion always takes place even if the conversion
lossy and irreversible, whereas column affinity only changes the data type
of a value if the change is lossless and reversible.

<p>^If the value of <i>expr</i> is NULL, then the result of the CAST
expression is also NULL. ^Otherwise, the storage class of the result
is determined by applying the [rules for determining column affinity] to
the <yyterm>type-name</yyterm>.

<blockquote>
<table border=1>
<tr>
  <th> Affinity of <yyterm><nobr>type-name</nobr></yyterm>
  <th> Conversion Processing
<tr>
  <td> NONE
  <td> ^Casting a value to a <yyterm>type-name</yyterm> with no affinity
  causes the value to
  be converted into a BLOB.  ^Casting to a BLOB consists of first casting
  the value to TEXT in the [encoding] of the database connection, then
  interpreting the resulting byte sequence as a BLOB instead of as TEXT.

<tr>
  <td> TEXT
  <td> ^To cast a BLOB value to TEXT, the sequence of bytes that make up the
  BLOB is interpreted as text encoded using the database encoding.
  <p>
   ^Casting an INTEGER or REAL value into TEXT renders the value as if via
    [sqlite3_snprintf()] except that the resulting TEXT uses the [encoding] of
    the database connection.

<tr>
  <td> REAL
  <td> ^When casting a BLOB value to a REAL, the value is first converted to
        TEXT.

        <p>^When casting to INTEGER, if the text looks like a floating point
        value with an exponent, the exponent will be ignored because it is
        no part of the integer prefix.  ^For example,
        "(CAST '123e+5' AS INTEGER)" results in 123, not in 12300000.

        <p> ^(The CAST operator understands decimal
        integers only &mdash; conversion of [hexadecimal integers] stops
        at the "x" in the "0x" prefix of the hexadecimal integer string
        and thus result of the CAST is always zero.)^

      <p>^A cast of a REAL value into an INTEGER results in the integer
      between the REAL value and zero that is closest to the REAL value.
      ^If a REAL is greater than the greatest possible signed
      integer (+9223372036854775807) then the result is the greatest possible
      signed integer and if the REAL is less than the least possible signed

  <td> NUMERIC
  <td> ^Casting a TEXT or BLOB value into NUMERIC yields either an INTEGER or
   a REAL result.
   ^If the input text looks like an integer (there is no decimal point nor
   exponent) and the value is small enough to fit in a 64-bit signed integer,
   then the result will be INTEGER.
   ^Input text that looks like floating point (there is a decimal point and/or
   an exponent) and the text describes a value that
   can be losslessly converted back and forth between IEEE 754 64-bit float and a
   51-bit signed integer, then the result is INTEGER.
   (In the previous sentence, a 51-bit integer is specified since that is one
   bit less than the length of the mantissa of an IEEE 754 64-bit float and
   thus provides a 1-bit of margin for the text-to-float conversion operation.)
   ^Any text input that describes a value outside the range of a 64-bit
   signed integer yields a REAL result.
   <p> ^Casting a REAL or INTEGER value to NUMERIC is a no-op, even if a real
   value could be losslessly converted to an integer.
</tr>
</table>
</blockquote>

<p>^Note that the result from casting any non-BLOB value into a
BLOB and the result from casting any BLOB value into a non-BLOB value
may be different depending on whether the database [encoding] is UTF-8,
UTF-16be, or UTF-16le.


<tcl>hd_fragment booleanexpr {boolean expression}</tcl>
<h1>Boolean Expressions</h1>

<p>The SQL language features several contexts where an expression is
evaluated and the result converted to a boolean (true or false) value. These
contexts are:

  <ul>
    <li> the WHERE clause of a SELECT, UPDATE or DELETE statement,
    <li> the ON or USING clause of a join in a SELECT statement,
    <li> the HAVING clause of a SELECT statement,
    <li> the WHEN clause of an SQL trigger, and
    <li> the WHEN clause or clauses of some CASE expressions.
  </ul>

<p>^(To convert the results of an SQL expression to a boolean value, SQLite
first casts the result to a NUMERIC value in the same way as a
[CAST expression]. A numeric zero value (integer value 0 or real
value 0.0) is considered to be false.  A NULL value is still NULL.
All other values are considered true.)^

<p>^(For example, the values NULL, 0.0, 0, 'english' and '0' are all considered
to be false.)^ ^(Values 1, 1.0, 0.1, -0.1 and '1english' are considered to
be true.)^

<p>Beginning with SQLite 3.23.0 ([dateof:3.23.0]), SQLite recognizes the
identifiers "TRUE" and "FALSE" as boolean literals, if and only if those
identifiers are not already used for some other meaning.  If there already
exists columns or tables or other objects named TRUE or FALSE, then for
the sake of backwards compatibility, the TRUE and FALSE identifiers refer

Upgrade only if you are having problems.
}

newsitem {2015-10-16} {Release 3.9.1} {
<p>SQLite [version 3.9.1] is a
[https://www.sqlite.org/src/vpatch?from=version-3.9.0&to=version-3.9.1|small patch]
to [version 3.9.0] that includes
a few simple build script and #ifdef tweaks to make the code easier to
compile on a wider variety of platform.  There are no functional changes,
except for a single
[https://www.sqlite.org/src/info/57eec374ae1d0a1d4a|minor bug-fix] in
[the json1 extension] to stop it from recognizing form-feed
(ASCII 0x0c) as a whitespace character, in conformance with
[http://www.rfc-editor.org/rfc/rfc7159.txt|RFC7159].
}

newsitem {2015-10-14} {Release 3.9.0} {
<p>SQLite version 3.9.0 is a regularly schedule maintenance release.
Key changes include:
<ul>

newsitem {2015-07-27} {Release 3.8.11} {
<p>SQLite version 3.8.11 is a regularly scheduled maintenance release.
   See the [version 3.8.11|change log] for details.
}

newsitem {2015-05-20} {Release 3.8.10.2} {
<p>Yikes!  Index corruption after a sequence of valid SQL statements!
<p>It has been many years since anything like
   [https://www.sqlite.org/src/info/34cd55d6|this bug] has snuck into
   an official SQLite release.  But for the pasts seven months
   ([version 3.8.7] through [version 3.8.10.1])
   if you do an INSERT into a carefully
   crafted schema in which there are two nested triggers that convert
   an index key value from TEXT to INTEGER and then back
   to TEXT again, the INTEGER value might get inserted as the index

}

newsitem {2015-05-07} {Release 3.8.10} {
<p>SQLite version 3.8.10 is a regularly scheduled maintenance release.
   This release features performance improvements, fixes to several
   arcane bugs found by the AFL fuzzer, the new "sqldiff.exe" command-line
   utility, improvements to the documentation, and other enhancements.
   See the <a href='releaselog/3_8_10.html'>release notes</a> for
   additional information.
}

newsitem {2015-04-08} {Release 3.8.9} {
<p>SQLite version 3.8.9 is a regularly scheduled maintenance release.
   New features in this release include the
   [PRAGMA index_xinfo] command, the [sqlite3_status64()] interface,
   and the ".dbinfo" command of the [command-line shell].
   See the <a href='releaselog/3_8_9.html'>release notes</a> for
   additional information.
}

newsitem {2015-02-25} {Release 3.8.8.3} {

   3.8.8 before it came into widespread use.

<p>See ticket
   [https://www.sqlite.org/src/info/f97c4637102a3ae72b7911|f97c4637102a3ae72b7911]
   for a description of the bug.

<p>The changes between versions 3.8.8 and 3.8.8.1 are minimal.
}

newsitem {2015-01-16} {Release 3.8.8} {
<p>SQLite [version 3.8.8] is a regularly schedule maintenance release of
   SQLite.

<p>There are no dramatic new features or performance enhancements in this
   release, merely incremental improvements.  Most of the performance gain

}

newsitem {2014-11-19} {Release 3.8.7.2} {
<p>SQLite [version 3.8.7.2] is a patch and bug-fix release.  Changes from
   the previous release are minimal.

<p>The primary reason for this release is to enhance the [ROLLBACK] command
   so that it allows running queries on the same database connection to
   continue running as long as the ROLLBACK does not change the schema.
   In all previous versions of SQLite, a ROLLBACK would cause pending
   queries to stop immediately and return [SQLITE_ABORT] or
   [SQLITE_ABORT_ROLLBACK]. Pending queries still abort if the ROLLBACK
   changes the database schema, but as of this patch release, the queries
   are allowed to continue running if the schema is unmodified.

<p>In addition to the ROLLBACK enhancement, this patch release also
   includes fixes for three obscure bugs.  See the
   [version 3.8.7.2|change log] for details.
}

newsitem {2014-10-30} {Release 3.8.7.1} {
<p>SQLite [version 3.8.7.1] is a bug-fix release.

<p>The primary reason for this bug-fix release is to address a problem with

   Upgrading from all prior versions is recommended.

<p>Most of the changes from the previous release have been micro-optimizations
   designed to help SQLite run a little faster.  Each individual optimization
   has an unmeasurably small performance impact.  But the improvements add up.
   Measured on a well-defined workload (which the SQLite developers use
   as a proxy for a typical application workload) using cachegrind on Linux
   and compiled with gcc 4.8.1 and -Os on x64 linux, the current release
   does over 20% more work for the same number of CPU cycles compared to the
   previous release.  Cachegrind is not a real CPU, and the workload
   used for measurement is only a proxy.  So your performance may vary.
   We expect to see about half the measured and reported improvement in
   real-world applications. 10% is less than 20% but it is still pretty
   good, we think.

   for further information.  In addition to fixing this bug, the
   [PRAGMA integrity_check] command has been enhanced to detect
   non-uniqueness in UNIQUE indices, so that if this bug did introduce
   any problems in databases, those problems can be easily detected.

<p>Other noteworthy changes include the addition of support for
   [hexadecimal integers] (ex: 0x1234), and performance enhancements
   to the [IN operator] which, according to
   [http://www.mail-archive.com/sqlite-users%40sqlite.org/msg85350.html|mailing list reports],
   help some queries run up to five times faster.

<p>Version 3.8.6 uses 25% fewer CPU cycles than version 3.8.0 from
   approximately one year ago, according to [http://valgrind.org/|valgrind]
   and the
   [http://www.sqlite.org/src/artifact/d29c8048beb7e|test/speedtest1.c]
   test program.
   On the other hand,
   the compiled binary for version 3.8.6 is about 5% larger than 3.8.0.
   The size increase is
   due in part to the addition of new features such as [WITHOUT ROWID]
   tables and [common table expressions].
}

newsitem {2014-06-04} {Release 3.8.5} {
<p>SQLite [version 3.8.5] is a regularly scheduled maintenance release.
   Upgrading from the previous version is recommended.

<p>Version 3.8.5 fixes more than a dozen obscure bugs.  None of these
   bugs should be a problem for existing applications.  Nor do any of
   the bugs represent a security vulnerability.  Nevertheless, upgrading
   is recommended to prevent future problems.

<p>In addition to bug fixes, the 3.8.5 release adds improvements to the
   query planner, especially regarding sorting using indices and handling
   OR terms
   in the WHERE clause for WITHOUT ROWID tables.  The ".system" and
   ".once" dot-commands were added to the command-line interface.  And
   there were enhancements to the FTS4 and RTREE virtual tables.  See
   the change log for details.
}

newsitem {2014-04-03} {Release 3.8.4.3} {
<p>The optimizations added in [version 3.8.4] caused some queries that involve
   subqueries in the FROM clause, DISTINCT, and ORDER BY clauses, to give an incorrect
   result.  See
   [http://www.sqlite.org/src/info/98825a79ce145686392d8074032ae54863aa21a3| ticket 98825a79ce145]
   for details.
   This release adds a
   [http://www.sqlite.org/src/fdiff?sbs=1&v1=7d539cedb1c&v2=ebad891b7494d&smhdr|one-character change]
   to a single line of code to fix the problem.
}

newsitem {2014-03-26} {Release 3.8.4.2} {
<p>The code changes that resulted in the performance improvements
   in [version 3.8.4] missed a single buffer overflow test, which could

decision was made to do a quick patch release to address both issues.
}

newsitem {2014-03-10} {Release 3.8.4} {
<p>SQLite [version 3.8.4] is a maintenance release featuring performance
   enhancements and fixes for a number of obscure bugs.
   There are no significant new features in SQLite version 3.8.4.
   However, the number of CPU cycles (measured by valgrind) needed to
   do many common operations has be reduced by about 12% relative to the
   previous release, and by about 25% relative to [version 3.7.16]
   from approximately one year ago.

<p>Version 3.8.4 of SQLite fixes several corner-case bugs that were
   found since the previous release.  These bugs were unlikely to appear
   in practice, and none represent a security vulnerability.
   Nevertheless, developers are encouraged to upgrade from all prior releases.
}

newsitem {2014-02-11} {Release 3.8.3.1} {
<p>SQLite [version 3.8.3.1] fixes a bug present in versions 3.8.1,
   3.8.2 and 3.8.3 that can cause queries to omit valid output rows.
   Upgrading from those versions is recommended.

<p>The problem only comes up if SQLite is compiled with either the
   [SQLITE_ENABLE_STAT3] or [SQLITE_ENABLE_STAT4] compile-time options.
   In that case, if a query has a WHERE clause that contains expressions
   like this:
   <blockquote>
WHERE (expr1 OR expr2 OR ... OR exprN) AND column IS NOT NULL
   </blockquote>

newsitem {2014-02-03} {Release 3.8.3} {
  <p>SQLite [version 3.8.3] is a regularly scheduled maintenance release.
  Upgrading from the previous release is optional.

  <p>The most visible change in version 3.8.3 is the addition of
  support for [common table expressions].  It is now possible to write a
  single [SELECT] statement that will query a tree or graph, using either
  a depth-first or a breadth-first search.  A single SQLite query will
  even [solve Sudoku puzzles] or [compute the Mandelbrot set].  As part
  of this change, SQLite now accepts a [VALUES clause] anyplace that
  a [SELECT] statement is valid.

  <p>This release also includes many small performance enhancements which
  should give a small speed boost to legacy applications.  And there are
  other minor enhancements such as the addition of the [printf()] SQL
  function.  See the [version 3.8.3|change log] for details.
}

newsitem {2013-12-06} {Release 3.8.2} {
  <p>SQLite [version 3.8.2] is a regularly scheduled maintenance release.
  Upgrading from the previous release is optional.

  <p>Version 3.8.2 adds support for [WITHOUT ROWID] tables.  This is a
  significant extension to SQLite.  Database files that contain WITHOUT ROWID
  tables are not readable or writable by prior versions of SQLite, however
  databases that do not use WITHOUT ROWID tables are fully backwards
  and forwards compatible.

  <p>The 3.8.2 release contains a potentially incompatible change.  In
  all prior versions of SQLite, a [cast] from a very large positive
  floating point number into an integer resulted in the most negative integer.
  In other words, CAST(+99.9e99 to INT) would yield -9223372036854775808.
  This behavior came about because it is what x86/x64 hardware does
  for the equivalent cast in the C language.  But the behavior is
  bizarre.  And so it has been changed effective with this release so that
  a cast from a floating point number into an integer returns the integer
  between the floating point value and zero that is closest to the floating
  point value.  Hence, CAST(+99.9e99 to INT) now returns +9223372036854775807.
  Since routines like [sqlite3_column_int64()] do an implicit cast if the
  value being accessed is really a floating point number, they are also
  affected by this change.

  <p>Besides the two changes mentioned above, the 3.8.2 release also
  includes a number of performance enhancements.  The
  [skip-scan optimization] is now available for databases that have been
  processed by [ANALYZE].  Constant SQL functions are now factored out of
  inner loops, which can result in a significant speedup for queries that
  contain WHERE clause terms like "date>datetime('now','-2 days')".  And
  various high-runner internal routines have been refactored for reduced
  CPU load.
}

newsitem {2013-10-17} {Release 3.8.1} {
  <p>SQLite [version 3.8.1] is a regularly scheduled maintenance release.
  Upgrading from the previous release is optional, though you should upgrade
  if you are using [partial indices] as there was a
  [http://www.sqlite.org/src/info/a5c8ed66ca|bug] related to partial
  indices in the previous release that could result in an incorrect answer
  for count(*) queries.

  <p>The [next generation query planner] that was premiered in the previous
  release continues to work well.
  The new query planner has been tweaked slightly
  in the current release to help it make better decisions in some
  cases, but is largely unchanged.  Two new SQL functions, [likelihood()] and
  [unlikely()], have been added to allow developers to give hints to the
  query planner without forcing the query planner into a particular decision.

  <p>Version 3.8.1 is the first SQLite release to take into account the

  record for a table or index.  Currently, row sizes are only used to help the
  query planner choose between a table or one of its indices when doing a
  table scan or a count(*) operation, though future releases are likely
  to use the estimated row size in other contexts as well.  The new
  [PRAGMA stats] statement can be used to view row size estimates.

  <p>Version 3.8.1 adds the [SQLITE_ENABLE_STAT4] compile-time option.
  STAT4 is very similar to STAT3 in that it uses samples from indices to
  try to guess how many rows of the index will be satisfy by WHERE clause
  constraints.  The difference is that STAT4 samples all columns of the
  index whereas the older STAT3 only sampled the left-most column.  Users
  of STAT3 are encouraged to upgrade to STAT4.  Application developers should
  use STAT3 and STAT4 with caution since both options, by design, violate
  the [query planner stability guarantee], making it more difficult to ensure
  uniform performance is widely-deployed and mass-produced embedded
  applications.
}

newsitem {2013-09-03} {Release 3.8.0.2} {
  <p>SQLite [version 3.8.0.2] contains a one-line fix to a bug in the

  <p>SQLite [version 3.8.0] might easily have been called "3.7.18" instead.
  However, this release features the cutover of the
  [next generation query planner] or [NGQP], and there is a small chance of
  [hazards of upgrading to the NGQP | breaking legacy programs] that
  rely on undefined behavior in previous SQLite releases, and so the
  minor version number was incremented for that reason.
  But the risks are low and there is a [query planner checklist] is
  available to application developers to aid in avoiding problems.

  <p>SQLite [version 3.8.0] is actually one of the most heavily tested
  SQLite releases ever.  Thousands and thousands of beta copies have
  be downloaded, and presumably tested, and there have been no problem
  reports.

  <p>In addition to the [next generation query planner], the 3.8.0 release
  adds support for [partial indices], as well as several other new features.
  See the [version 3.8.0 | change log] for further detail.
}

newsitem {2013-05-20} {Release 3.7.17} {
  SQLite [version 3.7.17] is a regularly schedule maintenance release.
  Visit the [version 3.7.17 | change log] for a full explanation of the
  changes in this release.

  There are many bug fixes in version 3.7.17.  But this does not indicate
  that 3.7.16 was a problematic release.  All of the bugs in 3.7.17 are
  obscure and are unlikely to impact any particular application.  And most
  of the bugs that are fixed in 3.7.17 predate 3.7.16 and have been in
  the code for years without ever before being noticed.
  Nevertheless, due to the large number of fixes,
  all users are encouraged to upgrade when possible.
}

newsitem {2013-04-12} {Release 3.7.16.2} {
  SQLite [version 3.7.16.2] fixes a long-standing flaw in the Windows
  OS interface that
  can result in database corruption under a rare race condition.
  See [http://www.sqlite.org/src/info/7ff3120e4f] for a full description
  of the problem.

  As far as we know, this bug has never been seen in the wild.  The
  problem was discovered by the SQLite developers while writing stress tests
  for a separate component of SQLite.  Those stress tests have not yet
  found any problems with the component they were intended to verify, but
  they did find the bug which is the subject of this patch release.

  Other than updates to version numbers, the only difference between this
  release and 3.7.16.1 is a two-character change in a single identifier,
  which is contained in the windows-specific OS interface logic.  There
  are no changes in this release (other than version numbers) for platforms
  other than Windows.
}

newsitem {2013-03-29} {Release 3.7.16.1} {
  SQLite [version 3.7.16.1] is a bug fix release that fixes a few problems
  that were present in the previous releases.

  The important bug fix is a problem that can lead to segfaults when using
  [shared cache mode] on a schema that contains a [COLLATE operator] within
  a [CHECK constraint] or within a [view].  Collating functions are associated
  with individual database connections.  But a pointer to the collating function
  was also being cached within expressions.  If an expression was part of the
  schema and contained a cached collating function, it would point to the
  collating function in the database connection that originally parsed the
  schema.  If that database connection closed while other database
  connections using the same shared cache continued to operate, they other
  database connections would try to use the deallocated collating function
  in the database connection that closed.  The fix in version 3.7.15 was to
  not cache collating function pointers in the expression structure but
  instead look them up each time a new statement is prepared.

  This release also contains some important enhancements to the query planner
  which should (we hope) make some queries run faster.  The enhancements
  include:

  <ol><li><p>When doing a full-table scan, try to use an index instead of
  the original table, under the theory that indices contain less information
  and are thus smaller and hence require less disk I/O to scan.</p>

  <li><p>Enhance the [IN operator] to allow it to make use of
  indices that have [affinity | numeric affinity].</p>

  <li><p>Do a better job of recognizing when an ORDER BY clause can be
  implemented using indices - especially in cases where the ORDER BY clause
  contains terms from two or more tables in a join.</p>
  </ol>
}

newsitem {2012-10-04} {Release 3.7.14.1} {
  SQLite [version 3.7.14.1] is a patch release.  Changes from the baseline

  terms in the WHERE clause.
}

newsitem {2012-06-11} {Release 3.7.13} {
  SQLite [version 3.7.13] adds support for WinRT and metro style
  applications for Microsoft Windows 8.  The 3.7.13 release is
  coming sooner than is usual after the previous release in order to get
  this new capability into the hands of developers.  To use SQLite in
  a metro style application, compile with the -DSQLITE_OS_WINRT flag.
  Because of the increased application security and safety requirements
  of WinRT, all database
  filenames should be full pathnames.  Note that SQLite is not capable
  of accessing databases outside the installation directory and application
  data directory.  This restriction is another security and safety feature
  of WinRT. Apart from these restrictions, SQLite should work exactly
  the same on WinRT as it does on every other system.

  Also in this release: when a database is opened using [URI filenames]
  and the [coreqp | mode=memory] query parameter
  then the database is an in-memory database, just as if it had
  been named ":memory:".  But, if shared cache mode is enabled, then
  all other database connections that specify the same URI filename
  will connect to the same in-memory database.  This allows two or more
  database connections (in the same process) to share the same in-memory
  database.

  SQLite [version 3.7.12] is a regularly scheduled maintenance release.
  This release contains several new optimizations and bug fixes and upgrading
  is recommended.  See the [version 3.7.12 | change summary] for details.
}

newsitem {2012-03-20} {Version 3.7.11} {
  SQLite [version 3.7.11] is a regularly scheduled maintenance release
  which was rushed out early due to a
  [http://www.sqlite.org/src/info/b7c8682cc1 | bug in the query optimizer]
  introduced in the previous release.  The bug is obscure - it changes
  a LEFT JOIN into an INNER JOIN in some cases when there is a 3-way join
  and OR terms in the WHERE clause.  But it was considered serious enough to
  rush out a fix.  Apart from this one problem, SQLite [version 3.7.10] has
  not given any trouble.  Upgrading to [version 3.7.11] from versions
  3.7.6.3, 3.7.7, 3.7.7.1, 3.7.8, or 3.7.9 is

newsitem {2012-01-16} {Version 3.7.10} {
  SQLite [version 3.7.10] is a regularly scheduled maintenance release.
  Upgrading from version 3.7.6.3, 3.7.7, 3.7.7.1, 3.7.8, or 3.7.9 is
  optional.  Upgrading from other releases is recommended.

  The [SQLITE_CONFIG_PCACHE] mechanism has been replaced with
  [SQLITE_CONFIG_PCACHE2].  If you do not know what this mechanism
  is (it is an extreme corner-case and is seldom used) then this
  change will not effect you in the least.

  The default [schema format number] for new database files has changed
  from 1 to 4.  SQLite has been able to generate and read database files
  using schema format 4 for six years.  But up unto now, the default
  schema format has been 1 so that older versions of SQLite could read
  and write databases generated by newer versions of SQLite.  But those
  older versions of SQLite have become so scarce now that it seems
  reasonable to make the new format the default.

  SQLite is changing some of the assumptions it makes above the behavior
  of disk drives and flash memory devices during a sudden power loss.
  This change is completely transparent to applications.
  Read about the [powersafe overwrite] property for additional information.

  <li> [sqlite3_uri_int64()]
  </ul>

  The [PRAGMA cache_size] statement has been enhanced.  Formerly, you would
  use this statement to tell SQLite how many pages of the database files it
  should hold in its cache at once.  The total memory requirement would
  depend on the database page size. Now, if you give [PRAGMA cache_size]
  a negative value -N, it will allocate roughly N
  [http://en.wikipedia.org/wiki/Kibibyte | kibibytes] of memory to cache,
  divided up according to page size.  This enhancement allows programs to
  more easily control their memory usage.

  There have been several obscure bug fixes.  One noteworthy bug,
  ticket [http://www.sqlite.org/src/info/ff5be73dee | ff5be73dee],
  could in theory result in a corrupt database file if a power loss

  Upgrading from version 3.7.6.3, 3.7.7, 3.7.7.1, and 3.7.8 is optional.
  Upgrading from other versions is recommended.

  The [SQLITE_ENABLE_STAT2] compile-time option is now a no-op.  The enhanced
  query-planner functionality formerly available using SQLITE_ENABLE_STAT2
  is now available through [SQLITE_ENABLE_STAT3].  The enhanced query planning
  is still disabled by default.  However, future releases of SQLite might
  convert STAT3 from an enable-option to a disable-option so that it is
  available by default and is only omitted upon request.

  The [FTS4] full-text search engine has been enhanced such that tokens in
  the search string that begin with "^" must be the first token in their
  respective columns in order to match.   Formerly, "^" characters in the
  search string were simply ignored.  Hence, if a legacy application was
  including "^" characters in FTS4 search strings, thinking that they would
  always be ignored, then those legacy applications might break with this
  update.  The fix is simply remove the "^" characters from the search
  string.

  See the [version 3.7.9 | change summary] for additional changes associated
  with this release.
}

newsitem {2011-September-19} {Version 3.7.8} {
  SQLite [version 3.7.8] is a quarterly maintenance release.  Upgrading from
  versions 3.7.6.3, 3.7.7, or 3.7.7.1 is optional.  Upgrading from other
  versions is recommended.

  This release features a new "external merge sort" algorithm used to
  implement ORDER BY and GROUP BY and also to presort the content of an
  index for CREATE INDEX.  The new algorithm does approximately the same
  number of comparisons and I/Os as before, but the I/Os are much more
  sequential and so runtimes are greatly reduced when the size of the
  set being sorted is larger than the filesystem cache.  The performance
  improvement can be dramatic - orders of magnitude faster
  for large CREATE INDEX commands.  On the other hand,
  the code is slightly slower (1% or 2%)
  for a small CREATE INDEX.  Since CREATE INDEX is not an
  operation that commonly occurs on a speed-critical path, we feel that
  this tradeoff is a good one.  The slight slowdown for small CREATE INDEX
  statements might be recovered in a future release.  ORDER BY and GROUP BY
  operations should now be faster for all cases, large and small.

  The query planner has been enhanced to do a better job of handling
  the DISTINCT keyword on SELECT statements.

  SQLite [version 3.7.7] is a regularly scheduled bi-monthly maintenance
  release.  Upgrading from version 3.7.6.3 is optional.  Upgrading from all
  prior releases is recommended.

  This release adds support for naming database files using [URI filenames].
  URI filenames are disabled by default (for backwards compatibility) but
  applications are encouraged to enable them since incompatibilities are
  likely to be exceedingly rare and the feature is useful.  See the
  [URI filenames | URI filename documentation] for details.

  Most of the other enhancements in this release involve
  [virtual tables].  The virtual table interface has been enhanced to
  support [SAVEPOINT] and [ON CONFLICT] clause processing, and the built-in
  [RTREE] and [FTS3 | FTS3/FTS4] have been augmented to take advantage of
  the new capability.  This means, for example, that it is now possible
  to use the [REPLACE] command on [FTS3 | FTS3/FTS4] and [RTREE] tables.

  The [FTS4] full-text index extension has been enhanced to support
  the [FTS4 prefix option] and the [FTS4 order option].  These two enhancements
  are provided in support of search-as-you-type interfaces where search
  results begin to appear after the first keystroke in the "search" box

  There has been a fair amount of work done on the FTS4 module for this
  release.  But the core SQLite code has changed little and the previous
  release has not given any problems, so we expect this to be a very
  stable release.
}

newsitem {2011-05-19} {Version 3.7.6.3} {
  SQLite [version 3.7.6.3] is a patch release that fixes a
  [http://www.sqlite.org/src/info/2d1a5c67df | single bug]
  associated with [WAL mode].  The bug has been in SQLite ever since WAL
  was added, but the problem is very obscure and so nobody has noticed
  before now.  Nevertheless, all users are encouraged to upgrade to
  version 3.7.6.3 or later.

  The bug is this:

  Transactions commit in WAL mode by adding a record onto the end of
  the WAL (the write-ahead log) that contains a "commit" flag.  So to
  commit a transaction, SQLite takes all the pages that have changed
  during that transaction, appends them to the WAL, and sets the commit
  flag on the last page.  Now, if SQLite comes under memory pressure, it
  might try to free up memory space by writing changed pages to the WAL
  prior to the commit.  We call this "spilling" the cache to WAL.  There
  is nothing wrong with spilling cache to WAL.  But if the
  memory pressure is severe, it might be that by the time [COMMIT] is run,
  all changed pages for the transaction have already been spilled to WAL
  and there are no pages left to be written to WAL.
  And with no unwritten pages, there was nothing to put the commit flag
  on.  And without a commit flag, the transaction would end up being
  rolled back.

newsitem {2011-04-13} {Version 3.7.6.1} {
  SQLite [version 3.7.6.1] fixes a single bug in 3.7.6 that can cause a
  segfault if [SQLITE_FCNTL_SIZE_HINT] is used on a unix build that has
  SQLITE_ENABLE_LOCKING_MODE set to 0 and is compiled with
  HAVE_POSIX_FALLOCATE.

  Upgrading from 3.7.6 is only needed for users effected by the
  configuration-specific bug described above.  There are no other changes
  to the code.
}

newsitem {2011-04-12} {Version 3.7.6} {
  SQLite [version 3.7.6] is a regularly scheduled bi-monthly maintenance
  release of SQLite.  Upgrading from version 3.7.5 is optional.  Upgrading
  releases prior to 3.7.5 is recommended.
}

newsitem {2011-02-01} {Version 3.7.5} {
  SQLite [version 3.7.5] is a regularly scheduled bi-monthly maintenance
  release of SQLite.  Due to the discovery and fix of
  [http://www.sqlite.org/src/tktview?name=5d863f876e | an obscure bug]
  that could cause database corruption, upgrading from all prior
  releases of SQLite is recommended.  This bug was found during code
  review and has not been observed in the wild.

  This release adds new [SQLITE_DBSTATUS_LOOKASIDE_HIT | opcodes] for the
  [sqlite3_db_status()] interface that allow more precise measurement of

}

newsitem {2010-12-08} {Version 3.7.4} {
  SQLite [version 3.7.4] is a regularly scheduled bi-monthly maintenance
  release of SQLite.  Upgrading from [version 3.7.2] and [version 3.7.3]
  is optional.  Upgrading from all other SQLite releases is recommended.

  This release features [full-text search] enhancements.  The older
  [FTS3] virtual table is still fully supported, and should also run
  faster.  In addition, the new [FTS4] virtual table is added.  FTS4
  follows the same syntax as FTS3 but holds additional metadata which
  facilitates some performance improvements and more advanced
  [matchinfo()] output.  Look for further full-text search enhancements
  in subsequent releases.

  Also in this release, the [EXPLAIN QUERY PLAN] output has been enhanced
  and new documentation is provided so that application developers can
  more easily understand how SQLite is performing their queries.

  Thanks to an account from the folks at [http://www.devio.us/], OpenBSD
  has been added to the list of platforms upon which we
  [tested | test SQLite] prior to every release.  That list of platforms
  now includes:

  <ul>
  <li> Linux x86 &amp; x86_64
  <li> MacOS 10.5 &amp; 10.6
  <li> MacOS 10.2 PowerPC
  <li> WinXP and Win7
  <li> Android 2.2
  <li> OpenBSD 4.7
  </ul>

  The previous release of SQLite ([version 3.7.3]) has proven to be very
  robust.  The only serious issue discovered was
  [http://www.sqlite.org/src/info/80ba201079 | ticket 80ba201079] that
  describes an incorrect query result that can occur under very
  unusual circumstances.  The ticket description contains details of the
  problem.  Suffice it to say here that the problem is very obscure and
  is unlikely to effect most applications and so upgrading is optional.
  The problem is fixed, of course, in this release.
}

newsitem {2010-October-08}  {Version 3.7.3} {
  SQLite [version 3.7.3] is a regularly scheduled bi-monthly maintenance
  release of SQLite.  Upgrading from [version 3.7.2] is optional.
  Upgrading from all other releases is recommended.

  This release adds two new interfaces (really just variations on existing
  interfaces).  The [sqlite3_create_function_v2()] interface adds a
  destructor for the application-data pointer.  The new
  [sqlite3_soft_heap_limit64()] interface allows the soft heap limit to
  be set to a value greater than 2<sup>31</sup>.

  The [RTREE] extension has been enhanced with the ability to have an
  [custom r-tree queries | application-defined query region].  This might
  be used, for example, to locate all objects within
  the field of view of a camera.

  The 3.7.3 release also includes some performance enhancements, including
  query planner improvements, documentation updates,
  and fixes to some very obscure bugs.
}

newsitem {2010-August-24} {Version 3.7.2} {
  SQLite [version 3.7.2] fixes a long-standing bug that can cause the
  database [free-page list] to go corrupt if [incremental_vacuum] is used
  multiple times to
  partially reduce the size of a database file that contains many hundreds
  of unused database pages.  The original bug reports together with links
  to the patch that fixes it can be seen
  <a href="http://www.sqlite.org/src/info/5e10420e8d">here</a>.

  This bug has been in the code for at least a year and possibly longer.
  The bug has nothing to do with the versions 3.7.1 or 3.7.0 or any other
  recent release.  The fact that the bug was discovered (and fixed)
  within hours of the 3.7.1 release is purely a coincidence.

  The bug is impossible to hit without using [incremental_vacuum] and is
  very difficult to hit even with incremental_vacuum.  And the kind of
  corruption that the bug causes can usually be fixed
  simply by running [VACUUM].  Nevertheless, because the bug can result
  in database corruption, it is recommended that all SQLite users upgrade
  to version 3.7.2 or later.
}

newsitem {2010-August-23} {Version 3.7.1} {
  SQLite [version 3.7.1] is a stabilization release for the 3.7.x series.
  Other than the filesize-in-header bug that was fixed in [version 3.7.0.1],
  no major problems have been seen in 3.7.0.  Some minor corner-case
  performance regressions have been fixed.  A typo in the OS/2 interface
  has been repaired.

  A biggest part of the 3.7.1 release is a cleanup and refactoring of
  the pager module within SQLite.  This refactoring should have no
  application-visible effects.  The purpose was to reorganize the code
  in ways that make it easier to prove correctness.

  The 3.7.1 release adds new experimental methods for obtained more
  detailed memory usage information and for controlling database file
  fragmentation.  And the query planner now does a better job of
  optimizing the [LIKE] and [GLOB] operators.

  This release increases the maximum size of database pages from 32KiB to
  64KiB.  A database with 64KiB pages will not be readable or writable by
  older versions of SQLite.  Note that further increases in page size

  SQLite version 3.7.0 also contains some query planner enhancements and
  a few obscure bug fixes, but the only really big change is the addition
  of WAL mode.
}

newsitem {2010-03-30} {Version 3.6.23.1} {
  SQLite [version 3.6.23.1] is a patch release to fix a bug in the
  offsets() function of [FTS3] at the request of the Mozilla.
}

newsitem {2010-03-09} {Version 3.6.23} {
  SQLite [version 3.6.23] is a regular bimonthly release of SQLite.
  Upgrading from the prior release is purely optional.

  This release contains new pragmas: the [secure_delete pragma], and

  removed.  SQLite has supported standard SQL [foreign key constraints]
  since [version 3.6.19] and so the ".genfkey" command was seen as
  an anachronism.
}

newsitem {2010-01-06} {Version 3.6.22} {
  SQLite [version 3.6.22] is a bug-fix release.  Two bugs have been fixed
  that might cause incorrect query results.
  <ul>
  <li>Ticket [http://www.sqlite.org/src/info/31338dca7e | 31338dca7e]
  describes a
  problem with queries that have a WHERE clause of the form (x AND y) OR z
  where x and z come from one table of a join and y comes from a different
  table.
  <li> Ticket [http://www.sqlite.org/src/info/eb5548a849 | eb5548a849]

newsitem {2009-12-07} {Version 3.6.21} {
  SQLite [version 3.6.21] focuses on performance optimization.  For
  a certain set of traces, this version uses 12% fewer CPU instructions
  than the previous release (as measured by Valgrind).  In addition, the
  [FTS3] extension has been through an extensive cleanup and rework and
  the [sqlite3_trace()] interface has been modified to insert
  [bound parameter] values into its output.
}

newsitem {2009-11-04} {Version 3.6.20} {
  SQLite [version 3.6.20] is a general maintenance release.  The
  query planner has been enhanced to work better with bound parameters
  in LIKE and GLOB operators and in range constraints and various minor

  trigger behavior will need to use the [recursive_triggers pragma]
  to disable recursive triggers.

  This version of SQLite also contains bug fixes, though none of the
  bugs are serious and all are obscure, so upgrading is optional.

  The SQLite core continues to have [test coverage | 100% branch test coverage]
  and so despite the many changes in this release, the developers
  believe that this version of SQLite is stable and ready for production
  use.
}

newsitem {2009-08-10} {Version 3.6.17} {
  This is a monthly maintenance release with a focus of bug fixes,
  performance improvements, and increased test coverage.  This is the
  first release of SQLite since [test coverage | 100% branch test coverage]
  was achieved on the SQLite core.

  In addition, a new interface [sqlite3_strnicmp()] is provided for the
  convenience of extension writers.

  None of the bugs fixed in this release are serious.  All bugs are
  obscure.  Upgrading is optional.
}

newsitem {2009-07-25} {100% Branch Test Coverage} {
  A subset of the [TH3] test suite was measured by gcov to provide
  [test coverage | 100% branch test coverage] over the SQLite core
  (exclusive of the VFS backend and of extensions such as FTS3 and RTREE)
  when compiled for SuSE 10.1 Linux on x86.  The SQLite developers pledge
  to maintain branch test coverage at 100% in all future releases.
  Ongoing work will strive for 100% branch test coverage on the
  operating-system backends and extensions as well.
}

newsitem {2009-06-27} {Version 3.6.16} {
  SQLite [version 3.6.16] is another general maintenance release containing
  performance and robustness enhancements.  A single notable bug was fixed
  (ticket #3929).  This bug can cause INSERT or UPDATE statements to fail
  on indexed tables that have AFTER triggers that modify the same table and
  index.
}

newsitem {2009-06-15} {Version 3.6.15} {
  SQLite [version 3.6.15] is a general maintenance release containing
  performance and robustness enhancements and fixes for various obscure
  bugs.
}

newsitem {2009-05-25} {Version 3.6.14.2} {
  SQLite [version 3.6.14.2] fixes an obscure bug in the code generator
  (ticket #3879)
  section of SQLite which can potentially cause incorrect query results.
  The changes from the prior release consist of only this one bug fix,
  check-in [6676]
  and a change to the version number text.

  The bug was introduced in version 3.6.14.  It is recommended that
  users of version 3.6.14 and 3.6.14.1 upgrade to this release.  Applications
  are unlikely to hit this bug, but since it is difficult to predict which
  applications might hit it and which might not, we recommend that all
  users of 3.6.14 and 3.5.14.1 upgrade to this release.
}

newsitem {2009-05-19} {Version 3.6.14.1} {
  SQLite [version 3.6.14.1] is a patch release to [version 3.6.14] with
  minimal changes that fixes three bugs.  Upgrading is only necessary
  for users who are impacted by one or more of those bugs.
}

newsitem {2009-05-07} {Version 3.6.14} {
  SQLite [version 3.6.14] provides new performance enhancements in
  the btree and pager layers and in the query optimizer.  Certain
  workloads can be as much as twice as fast as the previous release,

  can occur following a disk I/O error.
}

newsitem {2008-11-22} {Version 3.6.6.1} {
  This release fixes a bug that was introduced into SQLite [version 3.6.4]
  and that can cause database corruption in obscure cases.  This bug has
  never been seen in the wild; it was first detected by internal stress
  tests and required substantial analysis before it could be shown to
  potentially lead to corruption.  So we feel that SQLite versions 3.6.4,
  3.6.5, and 3.6.6 are safe to use for development work.  But upgrading
  to this patch release or later is recommended prior to deploying
  products that incorporate SQLite.

  We have taken the unusual step of issuing a patch release in order to
  get the fix for this bug into circulation quickly.  SQLite version 3.6.7
  will continue on its normal path of development with an anticipated
  release in mid December.
}


newsitem {2008-11-19} {Version 3.6.6} {
  SQLite [version 3.6.5] is released.  This is a quick turn-around release
  that fixes a bug in virtual tables and FTS3 that snuck into
  [version 3.6.5].  This release also adds the new
  application-defined page cache mechanism.
}

newsitem {2008-11-12} {Version 3.6.5} {
  SQLite [version 3.6.5] is released.  There are various minor feature
  enhancements and numerous obscure bug fixes.
  The [version 3.6.5|change log] contains the details.  Upgrading is
  optional.
}

newsitem {2008-11-01} {Bloomberg Joins SQLite Consortium} {
  The SQLite developers are honored to announce that
  [http://www.bloomberg.com/ | Bloomberg] has joined the

  recommended for all applications that make use of DISTINCT.
}

newsitem {2008-08-30} {Version 3.6.2} {
  SQLite version 3.6.2 contains rewrites of the page-cache subsystem and
  the procedures for matching identifiers to table columns in SQL statements.
  These changes are designed to better modularize the code and make it more
  maintainable and reliable moving forward.  Nearly 5000 non-comment lines
  of core code (about 11.3%) have changed
  from the previous release.  Nevertheless, there should be no
  application-visible changes, other than bug fixes.
}

newsitem {2008-08-06} {Version 3.6.1} {
  SQLite version 3.6.1 is a stabilization and performance enhancement
  release.
}

newsitem {2008-07-16} {Version 3.6.0 beta} {
  Version 3.6.0 makes changes to the [sqlite3_vfs | VFS] object in order
  to make SQLite more easily portable to a wider variety of platforms.
  There are potential incompatibilities with some legacy applications.
  See the [35to36 | 35to36.html] document for details.

  Version 3.5.9 is intended to be the last stable release prior to
  version 3.6.0.  Version 3.6.0 will make incompatible changes to the
  [sqlite3_vfs] VFS layer in order to address deficiencies in the original
  design.  These incompatibilities will only effect programmers who
  write their own custom VFS layers (typically embedded device builders).
  The planned VFS changes will be much smaller
  than the changes that occurred on the
  [34to35 | 3.4.2 to 3.5.0 transaction] that occurred last
  September.

  This release of SQLite is considered stable and ready for production use.
}

newsitem {2008-04-16} {Version 3.5.8} {

  an application-defined SQL function implementation to retrieve
  its [database connection] handle.

  This release of SQLite is considered stable and ready for production use.
}

newsitem {2008-03-17} {Version 3.5.7} {
  Version 3.5.7 fixes several minor and obscure bugs, especially
  in the autoconf-generated makefile.  Upgrading is optional.
  This release of SQLite is considered stable and ready for production use.
}

newsitem {2008-02-06} {Version 3.5.6} {
  Version 3.5.6 fixes a minor regression in 3.5.5 - a regression that
  had nothing to do with the massive change of the virtual machine

newsitem {2007-12-12} {SQLite Consortium Announced} {
  The <a href="consortium.html">SQLite Consortium</a> was launched
  today with [http://www.mozilla.org/ | Mozilla] and
  [http://www.symbian.com/ | Symbian] as charter members.
  As noted in the <a href="pressrelease-20071212.html">press release</a>,
  the Consortium's goal is to promote the continuing vitality and
  independence of SQLite.
}
newsitem {2007-11-27} {Version 3.5.3} {
  This is an incremental release that fixes several minor problems.
  Upgrading is optional.  If Version 3.5.2 or 3.5.1 is working fine
  for you, then there is no pressing need to change to 3.5.3.

  The prebuilt binaries and the amalgamation found on the
  <a href="download.html">download</a> page include the FTS3 fulltext
  search extension module.  We are doing this on an experimental
  basis and are not promising to provide prebuilt binaries with
  FTS3 in the future.
}

newsitem {2007-11-05} {Version 3.5.2} {
  This is an incremental release that fixes several minor problems,
  adds some obscure features, and provides some performance tweaks.
  Upgrading is optional.

  The experimental compile-time option
  [omitfeatures | SQLITE_OMIT_MEMORY_ALLOCATION] is no longer supported.  On the other
  hand, it is now possible to compile SQLite so that it uses a static
  array for all its dynamic memory allocation needs and never calls
  malloc.  Expect to see additional radical changes to the memory
  allocation subsystem in future releases.
}

newsitem {2007-10-04} {Version 3.5.1} {
  Fix a long-standing bug that might cause database corruption if a
  disk-full error occurs in the middle of a transaction and that
  transaction is not rolled back.
  Ticket #2686.

  The new VFS layer is stable.  However, we still reserve the right to
  make tweaks to the interface definition of the VFS if necessary.
}

newsitem {2007-09-04} {Version 3.5.0 alpha} {
  The OS interface layer and the memory allocation subsystems in
  SQLite have been reimplemented.  The published API is largely unchanged
  but the (unpublished) OS interface has been modified extensively.
  Applications that implement their own OS interface will require
  modification.  See
  <a href="34to35.html">34to35.html</a> for details.<p>

  This is a large change.  Approximately 10% of the source code was
  modified.  We are calling this first release "alpha" in order to give
  the user community time to test and evaluate the changes before we
  freeze the new design.
}

newsitem {2007-08-13} {Version 3.4.2} {
  While stress-testing the
  <a href="c3ref/soft_heap_limit.html">soft_heap_limit</a>
  feature, a bug that could lead to
  database corruption was discovered and fixed.
  Though the consequences of this bug are severe, the chances of hitting
  it in a typical application are remote.  Upgrading is recommended
  only if you use the
  <a href="c3ref/soft_heap_limit.html">sqlite3_soft_heap_limit</a>
  interface.
}

newsitem {2007-07-20} {Version 3.4.1} {
  This release fixes a bug in <a href="lang_vacuum.html">VACUUM</a> that
  can lead to database corruption.  The bug was introduced in version
  <a href="changes.html#version_3_3_14">3.3.14</a>.
  Upgrading is recommended for all users.  Also included are a slew of
  other more routine
  <a href="changes.html#version_3_4_1">enhancements and bug fixes</a>.
}

newsitem {2007-06-18} {Version 3.4.0} {
  This release fixes two separate bugs either of which
  can lead to database corruption.  Upgrading
  is strongly recommended.  If you must continue using an older version
  of SQLite, please at least read about how to avoid these bugs
  at CorruptionFollowingBusyError and ticket #2418
  <p>
  This release also adds explicit <a href="limits.html">limits</a> on the
  sizes and quantities of things SQLite will handle.  The new limits might
  causes compatibility problems for existing applications that
  use excessively large strings, BLOBs, tables, or SQL statements.
  The new limits can be increased at compile-time to work around any problems
  that arise.  Nevertheless, the version number of this release is
  3.4.0 instead of 3.3.18 in order to call attention to the possible
  incompatibility.
  </p>
  There are also new features, including
  <a href="c3ref/blob_open.html">incremental BLOB I/O</a> and
  <a href="pragma.html#pragma_incremental_vacuum">incremental vacuum</a>.
  See the <a href="changes.html#version_3_4_0">change log</a>
  for additional information.
}

newsitem {2007-04-25} {Version 3.3.17} {
  This version fixes a bug in the forwards-compatibility logic of SQLite
  that was causing a database to become unreadable when it should have
  been read-only.  Upgrade from 3.3.16 only if you plan to deploy into
  a product that might need to be upgraded in the future.  For day to day
  use, it probably does not matter.
}

newsitem {2007-04-18} {Version 3.3.16} {
  Performance improvements added in 3.3.14 but mistakenly turned off
  in 3.3.15 have been reinstated.  A bug has been fixed that prevented
  VACUUM from running if a NULL value was in a UNIQUE column.
}

newsitem {2007-04-09} {Version 3.3.15} {
  An annoying bug introduced in 3.3.14 has been fixed.  There are
  also many enhancements to the test suite.
}

newsitem {2007-04-02} {Version 3.3.14} {
  This version focuses on performance improvements.  If you recompile
  the amalgamation using GCC option -O3 (the precompiled binaries
  use -O2) you may see performance
  improvements of 35% or more over version 3.3.13 depending on your
  workload.  This version also
  adds support for <a href="pragma.html#pragma_locking_mode">
  exclusive access mode</a>.
}

newsitem {2007-02-13} {Version 3.3.13} {
  This version fixes a subtle bug in the ORDER BY optimizer that can
  occur when using joins.  There are also a few minor enhancements.
  Upgrading is recommended.
}

newsitem {2007-01-27} {Version 3.3.12} {
  The first published build of the previous version used the wrong
  set of source files.  Consequently, many people downloaded a build

  <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a>
  API and includes important bug fixes in the command-line
  shell and enhancements to the query optimizer.  Upgrading is
  recommended.
}

newsitem {2006-10-09} {Version 3.3.8} {
  Version 3.3.8 adds support for full-text search using the
  FTS1 module.  There are also minor bug fixes.  Upgrade only if
  you want to try out the new full-text search capabilities or if
  you are having problems with 3.3.7.
}

newsitem {2006-08-12} {Version 3.3.7} {
  Version 3.3.7 includes support for loadable extensions and virtual

newsitem {2006-04-5} {Version 3.3.5} {
  This release fixes many minor bugs and documentation typos and
  provides some minor new features and performance enhancements.
  Upgrade only if you are having problems or need one of the new features.
}

newsitem {2006-02-11} {Version 3.3.4} {
  This release fixes several bugs, including a
  blunder that might cause a deadlock on multithreaded systems.
  Anyone using SQLite in a multithreaded environment should probably upgrade.
}

newsitem {2006-01-31} {Version 3.3.3 stable} {
  There have been no major problems discovered in version 3.3.2, so
  we hereby declare the new APIs and language features to be stable

  of the default "PRAGMA synchronous=full".  There was an attempt to add
  this capability in 3.1.4 but it did not work due to a spelling error.
}

newsitem {2005-02-19} {Version 3.1.3 Released} {
  Version 3.1.3 cleans up some minor issues discovered in version 3.1.2.
}

newsitem {2005-02-15} {Versions 2.8.16 and 3.1.2 Released} {
  A critical bug in the VACUUM command that can lead to database
  corruption has been fixed in both the 2.x branch and the main
  3.x line.  This bug has existed in all prior versions of SQLite.
  Even though it is unlikely you will ever encounter this bug,
  it is suggested that all users upgrade.  See
  ticket #1116 for additional information.

  Version 3.1.2 is also the first stable release of the 3.1
  series.  SQLite 3.1 features added support for correlated
  subqueries, autovacuum, autoincrement, ALTER TABLE, and
  other enhancements.  See the
  <a href="releaselog/3_1_0.html">release notes
  for version 3.1.0</a> for a detailed description of the
  changes available in the 3.1 series.
}

newsitem {2005-02-01} {Version 3.1.1 (beta) Released} {
  Version 3.1.1 (beta) is now available on the
  website.  Version 3.1.1 is fully backwards compatible with the 3.0 series
  and features many new features including Autovacuum and correlated
  subqueries.  The
  <a href="releaselog/3_1_1.html">release notes</a>
  From version 3.1.0 apply equally to this release beta.  A stable release
  is expected within a couple of weeks.
}

newsitem {2005-01-21} {Version 3.1.0 (alpha) Released} {
  Version 3.1.0 (alpha) is now available on the
  website.  Version 3.1.0 is fully backwards compatible with the 3.0 series

  <a href="http://www.sqlite.org/tclconf2004/page-001.html">
  Slides</a> from the talk are available.
}

newsitem {2004-09-18} {Version 3.0.7} {
  Version 3.0 has now been in use by multiple projects for several
  months with no major difficulties.   We consider it stable and
  ready for production use.
}

newsitem {2004-09-02} {Version 3.0.6 (beta)} {
  Because of some important changes to sqlite3_step(),
  we have decided to
  do an additional beta release prior to the first "stable" release.
  If no serious problems are discovered in this version, we will

newsitem {2004-07-22} {Version 3.0.3 (beta)} {
  The second beta release of SQLite version 3.0 is now available.
  This new beta fixes many bugs and adds support for databases with
  varying page sizes.  The next 3.0 release will probably be called
  a final or stable release.

  Version 3.0 adds support for internationalization and a new
  more compact file format.
  <a href="version3.html">Details.</a>
  The API and file format have been fixed since 3.0.2.  All
  regression tests pass (over 100000 tests) and the test suite
  exercises over 95% of the code.

  SQLite version 3.0 is made possible in part by AOL
  developers supporting and embracing great Open-Source Software.
}

newsitem {2004-07-22} {Version 2.8.15} {
  SQLite version 2.8.15 is a maintenance release for the version 2.8
  series.  Version 2.8 continues to be maintained with bug fixes, but
  no new features will be added to version 2.8.  All the changes in
  this release are minor.  If you are not having problems, there is
  there is no reason to upgrade.
}

newsitem {2004-06-30} {Version 3.0.2 (beta) Released} {
  The first beta release of SQLite version 3.0 is now available.
  Version 3.0 adds support for internationalization and a new
  more compact file format.
  <a href="version3.html">Details.</a>
  As of this release, the API and file format are frozen.  All
  regression tests pass (over 100000 tests) and the test suite
  exercises over 95% of the code.

  SQLite version 3.0 is made possible in part by AOL
  developers supporting and embracing great Open-Source Software.
}


newsitem {2004-06-25} {Website hacked} {
  The www.sqlite.org website was hacked sometime around 2004-06-22
  because the lead SQLite developer failed to properly patch CVS.
  Evidence suggests that the attacker was unable to elevate privileges
  above user "cvs".  Nevertheless, as a precaution the entire website
  has been reconstructed from scratch on a fresh machine.  All services

  A new file format results in databases that are 25% smaller (depending
  on content).  The code is also a little faster.  In spite of the many
  new features, the library footprint is still less than 240KB
  (x86, gcc -O1).
  <a href="version3.html">Additional information</a>.

  Our intent is to freeze the file format and API on 2004-07-01.
  Users are encouraged to review and evaluate this alpha release carefully
  and submit any feedback prior to that date.

  The 2.8 series of SQLite will continue to be supported with bug
  fixes for the foreseeable future.
}

newsitem {2004-06-09} {Version 2.8.14 Released} {

<blockquote><pre>
[ATTACH] ':memory:' AS 'information_schema';
</pre></blockquote>
Then creating
[VIEW|VIEWs] in that schema that implement the official information schema
tables using table-valued PRAGMA functions.
<li><p>




The table-valued functions for PRAGMA feature was added
in SQLite version 3.16.0 ([dateof:3.16.0]).  Prior versions of SQLite
cannot use this feature.
</ul>
<tcl>

Pragma {analysis_limit} {

</tcl>

<h2>Licenses
<font size=2>(<a href="#ext">details below</a>)</font></h2>

<tcl>
support_entry 5 {SQLite License} {
  Warranty of title and perpetual right-to-use for the SQLite source code.
} {$6000 one time fee} \
  {{More Info} https://sqlite.org/copyright.html} \
  {{Purchase} https://sqlite.org/purchase/license}

support_entry 6 {SQLite Encryption Extension (SEE)} {
   A drop-in replacement for public-domain SQLite source code that has
   the added ability to read/write AES-encrypted databases.
} {$2000 one time fee} \
  {{More Info} https://sqlite.org/see/doc/release/www/readme.wiki} \
  {{Purchase} https://sqlite.org/purchase/see}

support_entry 7 {Compressed And Encrypted Read-Only Database (CEROD)} {
   A drop-in replacement for public-domain SQLite source code
   that has the added ability to read database that has been both
   compressed and encrypted.
} {$2000 one time fee} \
  {{More Info} https://sqlite.org/cerod/doc/release/www/readme.wiki} \
  {{Buy Now!} https://sqlite.org/purchase/cerod}

support_entry 8 {The ZIPVFS Read/Write Compressed Database Extension} {
   The ZIPVFS extension automatically compresses and encrypts
   your data as it is written to disk, and decompressed and decrypts

<h2>Special Services
<font size=2>(<a href="#th3">details below</a>)</font></h2>

<tcl>
support_entry 9 {TH3 Testing Support} {
  The <a href="https://sqlite.org/th3.html">TH3 test harness</a>
  is an aviation-grade test suite for SQLite. SQLite developers
  can run TH3 on specialized hardware and/or using specialized
  compile-time options, according to customer specification,
  either remotely or on customer premises. Pricing for this
  services is on a case-by-case basis depending on requirements.
} {call} \
  {{More Info} https://sqlite.org/th3.html} \
  {{Request A Quote} https://sqlite.org/com/contact.html}

generate_support_html
</tcl>

<a href="https://sqlite.org/forum/forummain">SQLite Forum</a>.
The forum is monitored by a large
community of experts, including the core SQLite development team,
who are able to resolve just about
any problems with SQLite that you are likely to have.</p>

<p>If you do not want to discuss your issues on a public and open forum, an
<a href="https://sqlite.org/com/ams.html">Annual Maintenance
Subscription</a> or "AMS" might
serve your needs better.
An AMS entitles you to private email support directly from the developers of
SQLite.  The level of support with an AMS is similar to the support one
gets from the public forum except that an AMS includes a unilateral
promise of non-disclosure, so with an AMS you can discuss your issues
with the SQLite developers in private, without the whole world watching.
An AMS costs $1500 per year.</p>

<p>Users with more advanced support needs can opt for a
<a href="https://sqlite.org/com/tech.html">Technical Support
Agreement</a>.
Technical support agreements are customized to the needs of each
individual client, but generally include direct telephone support
and priority handling of issues and bugs.  Guaranteed response time
is available as an option.  The cost of
technical support varies but is generally
in the range of $8000 to $35000 per year.</p>

<p>If SQLite is "mission critical" to your company, then you may
want to become an
<a href="https://sqlite.org/com/member.html">SQLite Consortium
Member</a>.  The SQLite
Consortium is a collaboration of companies who sponsor ongoing development
of SQLite in exchange for enterprise-level technical support, on-site
visits from the SQLite developers, unlimited access to all licensed
products, and strong guarantees that SQLite will remain in the public
domain, free and independent, and will not come under the control of
a competitor.</p>

<a name="ext"></a>
<h2>Software Licenses</h2>

<p>The SQLite source code is in the
<a href="https://sqlite.org/copyright.html">public domain</a>,
and is free for use
by anyone and for any purpose.  No license is required.  However, some
users desire a license so that they can have warranty of title, or just
because their company lawyers say they need one.  A
<a href="https://sqlite.org/purchase/license">perpetual license
and warranty of title</a>
for the core SQLite source code is available for this purpose.</p>

<p>The
<a href="https://sqlite.org/purchase/see">SQLite Encryption
Extension (SEE)</a>,
the <a href="https://sqlite.org/purchase/zipvfs">ZIPVFS Extension</a>,
and the <a href="https://sqlite.org/purchase/cerod">Compressed and
Encrypted ReadOnly Database (CEROD)</a> extension are enhanced versions
of SQLite that handle encrypted
and/or compressed databases.  SEE can read and write encrypted databases.
SEE encrypts all database content, including metadata, so that the database
file appears as white noise.  ZIPVFS
compresses the database on-the-fly using application-supplied
compression and decompression functions.
CEROD reads a compressed database that is
also optionally encrypted.  All of SEE, ZIPVFS, and CEROD are
supplied in source code form only; the licensee is responsible for
compiling the products for their chosen platform.  It is not difficult
to compile any of these extension.  All products come in the form of an
[amalgamation|{amalgamated source file}]
named "sqlite3.c".  So compiling SEE, ZIPVFS, or CEROD into an application
is simply a matter of substituting the SEE-, ZIPVFS-, or CEROD-enabled sqlite3.c
source file in place of the public-domain sqlite3.c source file and recompiling.
Licenses for SEE, ZIPVFS, and CEROD are perpetual.
All three extension can read and write ordinary,
uncompressed and unencrypted database files.</p>

<a name="th3"></a>
<h2>Testing Services</h2>

<p>The <a href="https://sqlite.org/th3.html">Test Harness #3 (TH3)</a> is
a suite of test cases for SQLite that provide 100% branch test coverage
(and 100% modified condition/decision coverage) for the core SQLite in
an as-deployed configuration using only published and documented interfaces.
TH3 is designed for use with embedded devices, and is compatible with
DO-178B.  Every release of the public-domain SQLite is tested using TH3,
and so all users benefit from the TH3 tests.  But the TH3 tests are not
themselves public.  Hardware or system manufactures who want to have
TH3 test run on their systems can negotiate a service agreement to have
the SQLite Developers run those tests.</p>

<h2>About The SQLite Team</h2>

<p>Paid support options and products are provided by
Hipp, Wyrick &amp; Company, Inc., (Hwaci), a
<a href="http://en.wikipedia.org/wiki/Georgia_(U.S._state)">Georgia</a>
corporation
with headquarters in
<a href="http://en.wikipedia.org/wiki/Charlotte,_North_Carolina">
Charlotte, North Carolina</a> and has been in business since
1992.
Hwaci has an international team of
employees and associates representing the best available talent.
We are a 100% engineering company.  There is
no sales staff.
Our goal is to provide outstanding service and honest advice
without spin or sales-talk.</p>

<p>Hwaci is a small company but it is
also closely held and debt-free and has low
fixed costs, which means that it is largely immune to buy-outs,
take-overs, and market down-turns.  Hwaci intends to
continue operating in its current form, and at roughly its current
size until at least the year 2050.
We expect to be here when you need us,
even if that need is many years in the future.</p>
</body></html>

  The SQLITE_DONE result code indicates that an operation has completed.
  The SQLITE_DONE result code is most commonly seen as a return value
  from [sqlite3_step()] indicating that the SQL statement has run to
  completion.  But SQLITE_DONE can also be returned by other multi-step
  interfaces such as [sqlite3_backup_step()].
}
RESCODE SQLITE_OK_LOAD_PERMANENTLY     {SQLITE_OK | (1<<8)} {
  The [sqlite3_load_extension()] interface loads an
  [loadable extension|extension] into a single
  database connection.  The default behavior is for that extension to be
  automatically unloaded when the database connection closes.  However,
  if the extension entry point returns SQLITE_OK_LOAD_PERMANENTLY instead
  of SQLITE_OK, then the extension remains loaded into the process address
  space after the database connection closes.  In other words, the
  xDlClose methods of the [sqlite3_vfs] object is not called for the
  extension when the database connection closes.
  <p>
  The SQLITE_OK_LOAD_PERMANENTLY return code is useful to
  [loadable extensions] that register new [VFSes], for example.
}
RESCODE SQLITE_AUTH_USER               {SQLITE_AUTH  | (1<<8)} {
  The SQLITE_AUTH_USER error code is an [ext-v-prim|extended error code]
  for [SQLITE_AUTH] indicating that an operation was attempted on a
  database for which the logged in user lacks sufficient authorization.
}

  The SQLITE_IOERR_CHECKRESERVEDLOCK error code is
  an [ext-v-prim|extended error code]
  for [SQLITE_IOERR] indicating an I/O error
  within the xCheckReservedLock method on the [sqlite3_io_methods] object.
}
RESCODE SQLITE_IOERR_LOCK              {SQLITE_IOERR | (15<<8)} {
  The SQLITE_IOERR_LOCK error code is an [ext-v-prim|extended error code]
  for [SQLITE_IOERR] indicating an I/O error in the
  advisory file locking logic.
  Usually an SQLITE_IOERR_LOCK error indicates a problem obtaining
  a [PENDING lock].  However it can also indicate miscellaneous
  locking errors on some of the specialized [VFSes] used on Macs.
}
RESCODE SQLITE_IOERR_CLOSE             {SQLITE_IOERR | (16<<8)} {
  The SQLITE_IOERR_ACCESS error code is an [ext-v-prim|extended error code]

  rather than an ordinary device failure. This often indicates a
  corrupt filesystem.
}
RESCODE SQLITE_LOCKED_SHAREDCACHE      {SQLITE_LOCKED |  (1<<8)} {
  The SQLITE_LOCKED_SHAREDCACHE error code is
  an [ext-v-prim|extended error code] for [SQLITE_LOCKED]
  indicating that the locking conflict has occurred due to contention
  with a different [database connection] that happens to hold a
  [shared cache] with the database connection to which the error was
  returned.  For example, if the other database connection is holding
  an [exclusive lock] on the database, then the database connection
  that receives this error will be unable to read or write any part
  of the database file unless it has the [read_uncommitted pragma]
  enabled.
  <p>
  The SQLITE_LOCKED_SHARECACHE error code works very much like the
  [SQLITE_BUSY] error code except that SQLITE_LOCKED_SHARECACHE is
  for separate database connections that share a cache whereas
  SQLITE_BUSY is for the much more common case of separate database
  connections that do not share the same cache.  Also, the
  [sqlite3_busy_handler()] and [sqlite3_busy_timeout()] interfaces
  do not help in resolving SQLITE_LOCKED_SHAREDCACHE conflicts.
}
RESCODE SQLITE_BUSY_RECOVERY           {SQLITE_BUSY   |  (1<<8)} {
  The SQLITE_BUSY_RECOVERY error code is an [ext-v-prim|extended error code]

    incr nExtCode
    set ext_rc($name) $val
  }
}

</tcl>
<h1>Primary Result Code List</h1>
<p>The <tcl>hd_puts $nPrimCode</tcl> result codes are
   [result code definitions|defined in sqlite3.h] and are listed in
   alphabetical order below:
<tcl>
set lx {}
foreach name [lsort [array names prim_rc]] {
  lappend lx [list $name "$name&nbsp;($prim_rc($name))" 0]
}
hd_list_of_links {} 320 $lx

<title>SQLite Session Module C/C++ Interface</title>

<h2>SQLite Session Module C/C++ Interface</h2>

<tcl>
file mkdir ${DEST}/session
set hdrfile [file join $SRC ext session sqlite3session.h]
set in [open $hdrfile]

set title {}       ;# title of a section of interface definition
set type {}        ;# one of: constant datatype function
set body {}        ;# human-readable description
set code {}        ;# C code of the definition
set phase 0        ;# Phase used by the parser
set content {}     ;# List of records, one record per definition
set dcnt 0         ;# Number of individual declarations
set lineno 0       ;# input file line number
set intab 0        ;# In a covenents or limitations table
set inrow 0        ;# In a row of a table
set rowbody {}     ;# Content of a row
set rowtag {}      ;#
set exflag 0       ;# True for experimental interfaces
set obsflag 0      ;# True for obsolete interfaces
unset -nocomplain keyword
unset -nocomplain supported   ;# 0: stable.  1: experimental  2: deprecated
unset -nocomplain fmeth

# End a table row or the complete table.
#

  global intab body
  endtab
  append body {<table border="0" cellpadding="5" cellspacing="0">}
  append body \n
  set intab 1
}

# Read sqlite3session.h line by line and extract interface
# definition information.
#
while {![eof $in]} {
  set line [gets $in]
  incr lineno
  if {$phase==0} {
    # Looking for the CAPI3REF: keyword.  This marks the beginning of
    # an interface definition.  When the CAPI3REF keywords is seen,
    # record the interface title and then switch to "phase 1".
    #
    if {[regexp {^\*\* CAPI3REF: +(.*)} $line all tx]} {
      set title $tx
      set dflt_parent {}
      regexp {<([AHLS]\d\d\d\d\d)>} $title all dflt_parent
      set title_lineno $lineno

hd_open_aux session/intro.html
hd_header Introduction
hd_enable_main 0
hd_keywords *session-capi {Session Extension C-language Interface}
</tcl>

<p>These pages define the C-language interface for the SQLite
[session extension].
This is not a tutorial. These pages are designed to be precise, not
easy to read.  A tutorial is [session|available separately].

<p>This version of the C-language interface reference is
broken down into small pages for easy viewing.  The
same content is also available as a
<a href="../session.html">single large HTML file</a>
for those who prefer that format.</p>

<p>The content on these pages is extracted from comments
in the source code.</p>

<p>The interface is broken down into three categories:</p>

<ol>
<li><p><a href="../session/objlist.html"><b>List Of Objects.</b></a>
    This is a list of the three abstract objects used by the SQLite session
    module.


<li><p><a href="../session/constlist.html"><b>List Of Constants.</b></a>
    This is a list of numeric constants used by the SQLite session module
    and represented by #defines in the sqlite3session.h header file. There
    are constants passed to conflict handler callbacks to indicate the type
    of conflict, and constants returned by the conflict handler to indicate
    how the conflict should be resolved.

<li><p><a href="../session/funclist.html"><b>List Of Functions.</b></a>
    This is a list of all SQLite session module functions.

</ol>

<tcl>
hd_close_aux
hd_enable_main 1
</tcl>

<p>This page defines the C-language interface to the SQLite
   [session extension].
   This is not a tutorial. These pages are designed to be precise, not easy
   to read.  A tutorial is [session extension|available separately].

<p>This page contains all C-language interface information
in a single HTML file.  The same information is also available
broken out into <a href="../session/intro.html">some smaller pages</a>
for easier viewing, if you prefer.</p>

<p>This document is created by a script which scans comments in the source
code file sqlite3session.h.</p>

<hr>

<tcl>
# Find the preferred keyword for a page given a list of
# acceptable keywords.

hd_enable_main 1
</tcl>
<h2>Objects:</h2>
<tcl>
hd_list_of_links {} 300 [lsort $objlist]
hd_enable_main 0
hd_putsnl {<p>Other lists:
<a href="../session/constlist.html">Constants</a> and
<a href="../session/funclist.html">Functions</a>.}
hd_close_aux
hd_enable_main 1
hd_putsnl {<hr>}

# Do a table of contents for constants
#
set clist {}

</tcl>
<h2>Constants:</h2>
<tcl>
set clist [lsort -index 1 $clist]
hd_list_of_links {} 400 $clist
hd_enable_main 0
hd_putsnl {<p>Other lists:
<a href="../session/objlist.html">Objects</a> and
<a href="../session/funclist.html">Functions</a>.</p>}
hd_enable_main 1
hd_close_aux
hd_putsnl {<hr>}


# Do a table of contents for functions
#

</tcl>
<h2>Functions:</h2>
<tcl>
set funclist [lsort -index 1 $funclist]
hd_list_of_links {} 300 $funclist
hd_enable_main 0
hd_putsnl {<p>Other lists:
<a href="../session/constlist.html">Constants</a> and
<a href="../session/objlist.html">Objects</a>.</p>}
hd_enable_main 1
hd_close_aux
hd_putsnl {<hr>}

# Convert a fragment text label into a fragment name
#
proc hd_fragname {lbl} {

  regsub -all "\n\n+" $body "</p>\n\n<p>" body
  hd_resolve <p>$body</p>
  show_methods_of_object c:$kw Constructor
  show_methods_of_object d:$kw Destructor
  show_methods_of_object m:$kw Method
  hd_enable_main 0
  hd_puts {<p>See also lists of
  <a href="../session/objlist.html">Objects</a>,
  <a href="../session/constlist.html">Constants</a>, and
  <a href="../session/funclist.html">Functions</a>.</p>}
  hd_enable_main 1
  hd_close_aux
  hd_puts "<hr>"
}
</tcl>

changes and Alice's changes.  Likewise, Bob can send a changeset of
his work over to Alice and she can apply his changes to her database.

<p>In other words, the session extension provides a facility for
SQLite database files that is similar to the unix
[https://en.wikipedia.org/wiki/Patch_(Unix)|patch] utility program,
or to the "merge" capabilities of version control systems such
as [https://www.fossil-scm.org/|Fossil], [https://git-scm.com|Git],
or [http://www.mercurial-scm.org/|Mercurial].

<h2>Obtaining the Session Extension</h2>

<p> Since [version 3.13.0] ([dateof:3.13.0]),
the session extension has been included in the SQLite
[amalgamation] source distribution. By default, the session extension is
disabled. To enable it, build with the following compiler switches:

<codeblock>
  -DSQLITE_ENABLE_SESSION -DSQLITE_ENABLE_PREUPDATE_HOOK
</codeblock>

<p> Or, if using the autoconf build system,
pass the --enable-session option to the configure script.

<h2>Limitations</h2>

<ul>

<li><p> Prior to SQLite version 3.17.0, the session extension only worked with
        [rowid tables], not [WITHOUT ROWID] tables. As of 3.17.0, both

        in PRIMARY KEY columns are recorded by the sessions module.
</ul>

<h1>Concepts</h1>

<tcl>hd_fragment changeset {changeset} {changesets} {patchset} {patchsets}</tcl>
<h2 id=changesets_and_patchsets>Changesets and Patchsets</h2>
<p> The sessions module revolves around creating and manipulating
changesets. A changeset is a blob of data that encodes a series of
changes to a database. Each change in a changeset is one of the
following:

<ul>
  <li> <p>An <b>INSERT</b>. An INSERT change contains a single row to add to
       a database table. The payload of the INSERT change consists of the
       values for each field of the new row.

  <li> <p>A <b>DELETE</b>. A DELETE change represents a row, identified by
       its primary key values, to remove from a database table. The payload
       of a DELETE change consists of the values for all fields of the
       deleted row.

  <li> <p>An <b>UPDATE</b>. An UPDATE change represents the modification of
       one or more non-PRIMARY KEY fields of a single row within a database
       table, identified by its PRIMARY KEY fields. The payload for an UPDATE
       change consists of:
   <ul>
     <li> The PRIMARY KEY values identifying the modified row,
     <li> The new values for each modified field of the row, and
     <li> The original values for each modified field of the row.
   </ul>
       <p> An UPDATE change does not contain any information regarding
       non-PRIMARY KEY fields that are not modified by the change. It is not
       possible for an UPDATE change to specify modifications to PRIMARY
       KEY fields.
</ul>

<p> A single changeset may contain changes that apply to more than one
database table. For each table that the changeset includes at least one change
for, it also encodes the following data:

<ul>
  <li> The name of the database table,
  <li> The number of columns the table has, and
  <li> Which of those columns are PRIMARY KEY columns.
</ul>

<p> Changesets may only be applied to databases that contain tables
matching the above three criteria as stored in the changeset.

<p> A patchset is similar to a changeset. It is slightly more compact than
a changeset, but provides more limited conflict detection and resolution
options (see the next section for details). The differences between a
patchset and a changeset are that:

<ul>
  <li><p> For a <b>DELETE</b> change, the payload consists of the PRIMARY KEY
          fields only. The original values of other fields are not stored as
          part of a patchset.

  <li><p> For an <b>UPDATE</b> change, the payload consists of the PRIMARY KEY
          fields and the new values of modified fields only. The original
          values of modified fields are not stored as part of a patchset.
</ul>

<h2>Conflicts</h2>

<p> When a changeset or patchset is applied to a database, an attempt is
made to insert a new row for each INSERT change, remove a row for each
DELETE change and modify a row for each UPDATE change. If the target
database is in the same state as the original database that the changeset
was recorded on, this is a simple matter. However, if the contents of the
target database is not in exactly this state, conflicts can occur when
applying the changeset or patchset.

<p>When processing an <b>INSERT</b> change, the following conflicts can
occur:

<ul>
  <li> The target database may already contain a row with the same PRIMARY
       KEY values as specified by the INSERT change.

  <li> Some other database constraint, for example a UNIQUE or CHECK
       constraint, may be violated when the new row is inserted.
</ul>

<p>When processing a <b>DELETE</b> change, the following conflicts may be
detected:

<ul>
  <li> The target database may contain no row with the specified PRIMARY
       KEY values to delete.

  <li> The target database may contain a row with the specified PRIMARY
       KEY values, but the other fields may contain values that do not
       match those stored as part of the changeset. This type of conflict
       is not detected when using a patchset.
</ul>

<p>When processing an <b>UPDATE</b> change, the following conflicts may be
detected:

<ul>
  <li> The target database may contain no row with the specified PRIMARY
       KEY values to modify.

  <li> The target database may contain a row with the specified PRIMARY
       KEY values, but the current values of the fields that will be modified
       by the change may not match the original values stored within the
       changeset. This type of conflict is not detected when using a patchset.

  <li> Some other database constraint, for example a UNIQUE or CHECK
       constraint, may be violated when the row is updated.
</ul>

<p> Depending on the type of conflict, a sessions application has a variety
of configurable options for dealing with conflicts, ranging from omitting the
conflicting change, aborting the entire changeset application or applying
the change despite the conflict. For details, refer to the documentation for
the [sqlite3changeset_apply()] API.

<h2>Changeset Construction</h2>

<p> After a session object has been configured, it begins monitoring for
changes to its configured tables. However, it does not record an entire
change each time a row within the database is modified. Instead, it records
just the PRIMARY KEY fields for each inserted row, and just the PRIMARY KEY
and all original row values for any updated or deleted rows. If a row is
modified more than once by a single session, no new information is recorded.

<p> The other information required to create a changeset or patchset is
read from the database file when [sqlite3session_changeset()] or
[sqlite3session_patchset()] is called. Specifically,

<ul>
  <li> <p>For each primary key recorded as a result of an INSERT operation,
       the sessions module checks if there is a row with a matching primary
       key still in the table. If so, an INSERT change is added to the
       changeset.

  <li> <p>For each primary key recorded as a result of an UPDATE or DELETE
       operation, the sessions module also checks for a row with a matching
       primary key within the table. If one can be found, but one or more
       of the non-PRIMARY KEY fields does not match the original recorded
       value, an UPDATE is added to the changeset. Or, if there is no row
       at all with the specified primary key, a DELETE is added to the
       changeset. If the row does exist but none of the non-PRIMARY KEY
       fields have been modified, no change is added to the changeset.
</ul>

<p> One implication of the above is that if a change is made and then
unmade within a single session (for example if a row is inserted and then
deleted again), the sessions module does not report any change at all. Or
if a row is updated multiple times within the same session, all updates
are coalesced into a single update within any changeset or patchset blob.

<h1>Using The Session Extension</h1>

<p> This section provides examples that demonstrate how to use the sessions
    extension.

<h2>Capturing a Changeset</h2>

<p> The example code below demonstrates the steps involved in capturing a
changeset while executing SQL commands. In summary:

<ol>
  <li> <p>A session object (type sqlite3_session*) is created by making a
          call to the [sqlite3session_create()] API function.

       <p>A single session object monitors changes made to a single database
          (i.e. "main", "temp" or an attached database) via a single
          sqlite3* database handle.

  <li> <p>The session object is configured with a set of tables to monitor
          changes on.

       <p> By default a session object does not monitor changes on any
           database table. Before it does so it must be configured. There
           are three ways to configure the set of tables to monitor changes
           on:
       <ul>
         <li> By explicitly specifying tables using one call to
              [sqlite3session_attach()] for each table, or

         <li> By specifying that all tables in the database should be monitored

  <li> <p> Changes are made to the database by executing SQL statements. The
           session object records these changes.

  <li> <p> A changeset blob is extracted from the session object using a call
           to [sqlite3session_changeset()] (or, if using patchsets, a call to
           the [sqlite3session_patchset()] function).

  <li> <p> The session object is deleted using a call to the
           [sqlite3session_delete()] API function.

       <p> It is not necessary to delete a session object after extracting
           a changeset or patchset from it. It can be left attached to the
           database handle and will continue monitoring for changes on the
           configured tables as before. However, if
           [sqlite3session_changeset()] or [sqlite3session_patchset()] is
           called a second time on a session object, the changeset or patchset
           will contain <em>all</em> changes that have taken place on the connection
           since the session was created. In other words,
           a session object is not reset or
           zeroed by a call to sqlite3session_changeset() or
           sqlite3session_patchset().
</ol>

<codeblock class=C>
  /*
  ** Argument zSql points to a buffer containing an SQL script to execute
  ** against the database handle passed as the first argument. As well as
  ** executing the SQL script, this function collects a changeset recording
  ** all changes made to the "main" database file. Assuming no error occurs,
  ** output variables (*ppChangeset) and (*pnChangeset) are set to point
  ** to a buffer containing the changeset and the size of the changeset in
  ** bytes before returning SQLITE_OK. In this case it is the responsibility
  ** of the caller to eventually free the changeset blob by passing it to

<h2>Applying a Changeset to a Database</h2>

<p> Applying a changeset to a database is simpler than capturing a changeset.
Usually, a single call to [sqlite3changeset_apply()], as depicted in the
example code below, suffices.

<p> In cases where it is complicated, the complications in applying a
changeset lie in conflict resolution. Refer to the API documentation linked
above for details.

  <codeblock class=C>
    /*
    ** Conflict handler callback used by apply_changeset(). See below.
    */
    static int xConflict(void *pCtx, int eConflict, sqlite3_changset_iter *pIter){
      int ret = (int)pCtx;
      return ret;
    }

    /*
    ** Apply the changeset contained in blob pChangeset, size nChangeset bytes,
    ** to the main database of the database handle passed as the first argument.
    ** Return SQLITE_OK if successful, or an SQLite error code if an error
    ** occurs.
    **
    ** If parameter bIgnoreConflicts is true, then any conflicting changes
    ** within the changeset are simply ignored. Or, if bIgnoreConflicts is
    ** false, then this call fails with an SQLTIE_ABORT error if a changeset
    ** conflict is encountered.
    */
    int apply_changeset(
      sqlite3 *db,                  /* Database handle */
      int bIgnoreConflicts,         /* True to ignore conflicting changes */
      int nChangeset,               /* Size of changeset in bytes */
      void *pChangeset              /* Pointer to changeset blob */
    ){
      return sqlite3changeset_apply(
          db,
          nChangeset, pChangeset,
          0, xConflict,
          (void*)bIgnoreConflicts
      );
    }
</codeblock>

<h2>Inspecting the Contents of a Changeset</h2>

<p> The example code below demonstrates the techniques used to iterate
through and extract the data related to all changes in a changeset. To
summarize:

<ol>
  <li><p> The [sqlite3changeset_start()] API is called to create and
          initialize an iterator to iterate through the contents of a
          changeset. Initially, the iterator points to no element at all.

  <li><p> The first call to [sqlite3changeset_next()] on the iterator moves
          it to point to the first change  in the changeset (or to EOF, if
          the changeset is completely empty). sqlite3changeset_next() returns
          SQLITE_ROW if it moves the iterator to point to a valid entry,
          SQLITE_DONE if it moves the iterator to EOF, or an SQLite error
          code if an error occurs.

  <li><p> If the iterator points to a valid entry, the [sqlite3changeset_op()]
          API may be used to determine the type of change (INSERT, UPDATE or
          DELETE) that the iterator points to. Additionally, the same API
          can be used to obtain the name of the table the change applies to
          and its expected number of columns and primary key columns.

  <li><p> If the iterator points to a valid INSERT or UPDATE entry, the
          [sqlite3changeset_new()] API may be used to obtain the new.* values
          within the change payload.

  <li><p> If the iterator points to a valid DELETE or UPDATE entry, the
          [sqlite3changeset_old()] API may be used to obtain the old.* values
          within the change payload.

  <li><p> An iterator is deleted using a call to the
          [sqlite3changeset_finalize()] API. If an error occured while
          iterating, an SQLite error code is returned (even if the same error
          code has already been returned by sqlite3changeset_next()). Or,
          if no error has occurred, SQLITE_OK is returned.
</ol>

  <codeblock class=C>

<h1>Extended Functionality</h1>

<p> Most applications will only use the session module functionality described
in the previous section. However, the following additional functionality is
available for the use and manipulation of changeset and patchset blobs:

<ul>
  <li> <p>Two or more changeset/patchsets may be combined using the
       [sqlite3changeset_concat()] or [sqlite3_changegroup] interfaces.

  <li> <p>A changeset may be "inverted" using the [sqlite3changeset_invert()]
       API function. An inverted changeset undoes the changes made by the
       original. If changeset C<sup>+</sup> is the inverse of changeset C, then
       applying C and then C<sup>+</sup> to a database should leave
       the database unchanged.

<title>SQLite Shared-Cache Mode</title>
<tcl>hd_keywords {SQLite Shared-Cache Mode} \
        {shared cache} {shared cache mode}</tcl>

<table_of_contents>

<tcl>hd_fragment sqlite_shared_cache_mode</tcl>
<h1>SQLite Shared-Cache Mode</h1>

<p>Starting with [version 3.3.0] ([dateof:3.3.0]),
SQLite includes a special "shared-cache"
mode (disabled by default) intended for use in embedded servers. If
shared-cache mode is enabled and a thread establishes multiple connections
to the same database, the connections share a single data and schema cache.
This can significantly reduce the quantity of memory and IO required by
the system.</p>

<p>In [version 3.5.0] ([dateof:3.5.0]),
shared-cache mode was modified so that the same
cache can be shared across an entire process rather than just within
a single thread.  Prior to this change, there were restrictions on
passing database connections between threads.  Those restrictions were
dropped in 3.5.0 update.  This document describes shared-cache mode
as of version 3.5.0.</p>

is discouraged.  Most use cases for shared-cache are better served by
[WAL mode].

<p>Shared-cache mode was invented in 2006 at the request of developers
of [https://en.wikipedia.org/wiki/Symbian|Symbian].  Their problem was that
if the contacts database on the phone was being synced, that would lock the
database file.  Then if a call came in, the database lock would prevent them
from querying the contacts database in order to find the appropriate
ring-tone for the incoming call, or a photo of the caller to show on screen,
and so forth.
[WAL mode] (circa 2010) is a better solution to this problem as it permits
simultaneous access without breaking transaction isolation.

<p>Applications that build their own copy of SQLite from source code
are encouraged to use the [-DSQLITE_OMIT_SHARED_CACHE] compile-time option,
as the resulting binary will be both smaller and faster.

<p>The shared-cache interfaces described here will continue to be supported
in SQLite, to insure full backwards compatibility.  However, the use of
shared-cache is discouraged.

<h1>Shared-Cache Locking Model</h1>

<p>Externally, from the point of view of another process or thread, two
or more [sqlite3|database connections] using a shared-cache appear as a single
connection. The locking protocol used to arbitrate between multiple
shared-caches or regular database users is described elsewhere.
</p>

<table style="margin:auto">
<tr><td>
<img src="images/shared.gif">
<!-- <pre>

          +----------------+
          |    Database    |
          +----------------+
</pre> -->
</table>
<p style="font-style:italic;text-align:center">Figure 1</p>

<p>Figure 1 depicts an example runtime configuration where three
database connections have been established. Connection 1 is a normal
SQLite database connection. Connections 2 and 3 share a cache
The normal locking
protocol is used to serialize database access between connection 1 and
the shared cache. The internal protocol used to serialize (or not, see
"Read-Uncommitted Isolation Mode" below) access to the shared-cache by
connections 2 and 3 is described in the remainder of this section.
</p>

<p>There are three levels to the shared-cache locking model,
transaction level locking, table level locking and schema level locking.
They are described in the following three sub-sections.</p>

<h2>Transaction Level Locking</h2>

<p>SQLite connections can open two kinds of transactions, read and write
transactions. This is not done explicitly, a transaction is implicitly a
read-transaction until it first writes to a database table, at which point
it becomes a write-transaction.
</p>
<p>At most one connection to a single shared cache may open a
write transaction at any one time. This may co-exist with any number of read
transactions.
</p>

<h2>Table Level Locking</h2>

<p>When two or more connections use a shared-cache, locks are used to
serialize concurrent access attempts on a per-table basis. Tables support
two types of locks, "read-locks" and "write-locks". Locks are granted to
connections - at any one time, each database connection has either a
read-lock, write-lock or no lock on each database table.
</p>

<p>At any one time, a single table may have any number of active read-locks
or a single active write lock. To read data from a table, a connection must
first obtain a read-lock. To write to a table, a connection must obtain a
write-lock on that table. If a required table lock cannot be obtained,
the query fails and SQLITE_LOCKED is returned to the caller.
</p>

<p>Once a connection obtains a table lock, it is not released until the
current transaction (read or write) is concluded.
</p>

<h3>Read-Uncommitted Isolation Mode</h3>

<p>The behaviour described above may be modified slightly by using the
[read_uncommitted] pragma to change the isolation level from serialized
(the default), to read-uncommitted.</p>

<p> A database connection in read-uncommitted mode does not attempt
to obtain read-locks before reading from database tables as described
above. This can lead to inconsistent query results if another database
connection modifies a table while it is being read, but it also means that
a read-transaction opened by a connection in read-uncommitted mode can
neither block nor be blocked by any other connection.</p>

<p>Read-uncommitted mode has no effect on the locks required to write to
database tables (i.e. read-uncommitted connections must still obtain
write-locks and hence database writes may still block or be blocked).
Also, read-uncommitted mode has no effect on the [sqlite_schema]
locks required by the rules enumerated below (see section
"Schema (sqlite_schema) Level Locking").
</p>

<blockquote><pre>
  /* Set the value of the read-uncommitted flag:
  **
  **   True  -> Set the connection to read-uncommitted mode.
  **   False -> Set the connection to serialized (the default) mode.
  */
  PRAGMA read_uncommitted = &lt;boolean&gt;;

  /* Retrieve the current value of the read-uncommitted flag */
  PRAGMA read_uncommitted;
</pre></blockquote>

<h2>Schema (sqlite_schema) Level Locking</h2>

<p>The [sqlite_schema table] supports shared-cache read and write
locks in the same way as all other database tables (see description
above). The following special rules also apply:
</p>

<ul>
<li>A connection must obtain a read-lock on <i>sqlite_schema</i> before
accessing any database tables or obtaining any other read or write locks.</li>
<li>Before executing a statement that modifies the database schema (i.e.
a CREATE or DROP TABLE statement), a connection must obtain a write-lock on
<i>sqlite_schema</i>.
</li>
<li>A connection may not compile an SQL statement if any other connection
is holding a write-lock on the <i>sqlite_schema</i> table of any attached
database (including the default database, "main").
</li>
</ul>

<h1>Thread Related Issues</h1>

<p>In SQLite versions 3.3.0 through 3.4.2 when shared-cache mode is enabled,
a database connection may only be
used by the thread that called [sqlite3_open()] to create it.
And a connection could only share cache with another connection in the
same thread.
These restrictions were dropped beginning with SQLite
[version 3.5.0] ([dateof:3.5.0]).
</p>

<h1>Shared Cache And Virtual Tables</h1>

<p>
In older versions of SQLite,
shared cache mode could not be used together with virtual tables.
This restriction was removed in SQLite [version 3.6.17] ([dateof:3.6.17]).

<h1>Enabling Shared-Cache Mode</h1>

<p>Shared-cache mode is enabled on a per-process basis. Using the C
interface, the following API can be used to globally enable or disable
shared-cache mode:
</p>

<blockquote><pre>
int sqlite3_enable_shared_cache(int);
</pre></blockquote>

ATTACH 'file:aux.db?cache=shared' AS aux;
</pre></blockquote>

<tcl> hd_fragment inmemsharedcache {in-memory shared-cache} </tcl>
<h1>Shared Cache And In-Memory Databases</h1>

<p>
Beginning with SQLite [version 3.7.13] ([dateof:3.7.13]),
shared cache can be used on
[in-memory databases], provided that the database is created using
a [URI filename].  For backwards compatibility, shared cache is always
disabled for in-memory
databases if the unadorned name ":memory:" is used to open the database.
Prior to version 3.7.13, shared cache was always
disabled for in-memory databases regardless of the database name used,

# facilitate that, all the size values are defined by variables here
# which are then used as needed through the document.
#
# NOTE:  Also update the version number in the text!!!
#

# sloc sqlite3.c
set stat(coreSLOC)   151268  ;# Non-comment lines of amalgamation code
# sloc test*.c
set stat(tclcSLOC)    27667  ;# Non-comment lines of test C code
# ls test*.c tclsqlite.c | wc
set stat(tclcNfile)      50  ;# Number of files of TCL C testcode + tclsqlite.c
# ls -l test*.c tclsqlite.c | awk '{sum+=$5}END{print sum}'
set stat(tclcNByte) 1279224  ;# Number of bytes of TCL C testcode + tclsqlite.c
# sloc `find . -name '*.test' -print` test/*.tcl

set stat(totalSLOC) [expr {$stat(tclcSLOC)+$stat(tclsSLOC)+
                           $stat(th3SLOC)+$stat(sltcSLOC)+$stat(sltsSLOC)}]

proc GB {expr} {
  set n [uplevel #0 expr $expr]
  hd_puts [format %.2f [expr {$n/(1000.0*1000.0*1000.0)}]]
}
proc MiB {expr} {
  set n [uplevel #0 expr $expr]
  hd_puts [format %.1f [expr {$n/(1024.0*1024.0)}]]
}
proc MB {expr} {
  set n [uplevel #0 expr $expr]
  hd_puts [format %.1f [expr {$n/(1000.0*1000.0)}]]
}
proc KiB {expr} {
  set n [uplevel #0 expr $expr]
  hd_puts [format %.1f [expr {$n/(1024.0)}]]
}
proc KB {expr} {
  set n [uplevel #0 expr $expr]
  hd_puts [format %.1f [expr {$n/(1000.0)}]]
}
proc N {expr} {
  hd_puts [uplevel #0 expr $expr]
}

<tcl>KB {$stat(coreSLOC)}</tcl> KSLOC of C code.
(KSLOC means thousands of "Source Lines Of Code" or, in other words,
lines of code excluding blank lines and comments.)
By comparison, the project has
<tcl>
hd_puts "[expr {int($stat(totalSLOC)/$stat(coreSLOC))}] times as much"
</tcl>
test code and test scripts -
<tcl>KB {$stat(totalSLOC)}</tcl> KSLOC.</p>

<h2>Executive Summary</h2>

<ul>
<li> Four independently developed test harnesses
<li> 100% branch test coverage in an as-deployed configuration

<li> Undefined behavior checks
<li> Checklists
</ul>

<tcl>hd_fragment {harnesses} {test harness} {three test harnesses}</tcl>
<h1>Test Harnesses</h1>

<p>There are four independent test harnesses used for testing the
core SQLite library.
Each test harness is designed, maintained, and managed separately
from the others.
</p>

<ol>
<li><p>
<tcl>hd_fragment tcl {TCL test suite}</tcl>
The <b>TCL Tests</b> are the original tests for SQLite.
They are contained in the same source tree as the
SQLite core and like the SQLite core are in the public domain.  The
TCL tests are the primary tests used during development.
The TCL tests are written using the
[http://www.tcl-lang.org/ | TCL scripting language].
The TCL test harness itself consists of <tcl>KB {$stat(tclcSLOC)}</tcl> KSLOC
of C code used to create the TCL interface.  The test scripts are contained
in <tcl>N {$stat(tclsNFile)}</tcl> files totaling
<tcl>MiB {$stat(tclsNByte)}</tcl>MB in size.  There are
<tcl>N {$stat(tclNTest)}</tcl> distinct test cases, but many of the test
cases are parameterized and run multiple times (with different parameters)
so that on a full test run millions of
separate tests are performed.
</p>
</li>

<li><p>
The <b>[TH3]</b> test harness is a set of proprietary tests, written in
C that provide 100% branch test coverage
(and [MC/DC|100% MC/DC test coverage]) to
the core SQLite library.  The TH3 tests are designed to run
on embedded and specialized platforms that would not easily support
TCL or other workstation services.  TH3 tests use only the published
SQLite interfaces. TH3 consists of about
<tcl>MB {$stat(th3NByte)}</tcl> MB or <tcl>KB {$stat(th3SLOC)}</tcl> KSLOC
of C code implementing <tcl>N {$stat(th3NTest)}</tcl> distinct test cases.
TH3 tests are heavily parameterized, though, so a full-coverage test runs
about <tcl>MB {$stat(th3NECov)}</tcl> million different test
instances.  The cases that provide 100% branch test coverage constitute
a subset of the total TH3 test suite.  A soak test

SQLite against PostgreSQL, MySQL, Microsoft SQL Server, and Oracle 10g.
SLT runs <tcl>MB {$stat(sltNTest)}</tcl> million queries comprising
<tcl>GB {$stat(sltsNByte)}</tcl>GB of test data.
</p></li>

<li><p>
The <a href="#dbsqlfuzz"><b>dbsqlfuzz</b></a> engine is a
proprietary fuzz tester.  Other [fuzz testing|fuzzers for SQLite]
mutate either the SQL inputs or the database file.  Dbsqlfuzz mutates
both the SQL and the database file at the same time, and is thus able
to reach new error states.  Dbsqlfuzz is built using the
[http://llvm.org/docs/LibFuzzer.html|libFuzzer] framework of LLVM
with a custom mutator.  There are
<tcl>hd_puts $stat(nfuzzseed)</tcl> seed files. The dbsqlfuzz fuzzer
runs about one billion test mutations per day.
Dbsqlfuzz helps ensure
that SQLite is robust against attack via malicious SQL or database
inputs.
</ol>

<p>In addition to the four main test harnesses, there several other
small programs that implement specialized tests.
<ol>
<li value="5">The "speedtest1.c" program
estimates the performance of SQLite under a typical workload.
<li>The "mptester.c" program is a stress test for multiple processes
concurrently reading and writing a single database.
<li>The "threadtest3.c" program is a stress test for multiple threads using
SQLite simultaneously.
<li>The "fuzzershell.c" program is used to
run some <a href="#fuzztesting">fuzz tests</a>.
</ol>
</p>

<p>All of the tests above must run successfully, on multiple platforms
and under multiple compile-time configurations,
before each release of SQLite.</p>

<p>Prior to each check-in to the SQLite source tree, developers
typically run a subset (called "veryquick") of the Tcl tests
consisting of about
<tcl>KB {$stat(vqNEval)}</tcl> thousand test cases.
The veryquick tests include most tests other than the anomaly, fuzz, and
soak tests.  The idea behind the veryquick tests are that they are
sufficient to catch most errors, but also run in only a few minutes
instead of a few hours.</p>

<tcl>hd_fragment anomaly</tcl>
<h1>Anomaly Testing</h1>

SQLite is frequently used on embedded devices, it is important that
SQLite be able to gracefully handle OOM errors.</p>

<p>OOM testing is accomplished by simulating OOM errors.
SQLite allows an application to substitute an alternative malloc()
implementation using the [sqlite3_config]([SQLITE_CONFIG_MALLOC],...)
interface.  The TCL and TH3 test harnesses are both capable of
inserting a modified version of malloc() that can be rigged to fail
after a certain number of allocations.  These instrumented mallocs
can be set to fail only once and then start working again, or to
continue failing after the first failure.  OOM tests are done in a
loop.  On the first iteration of the loop, the instrumented malloc
is rigged to fail on the first allocation.  Then some SQLite operation
is carried out and checks are done to make sure SQLite handled the
OOM error correctly.  Then the time-to-failure counter
on the instrumented malloc is increased by one and the test is
repeated.  The loop continues until the entire operation runs to
completion without ever encountering a simulated OOM failure.
Tests like this are run twice, once with the instrumented malloc
set to fail only once, and again with the instrumented malloc set
to fail continuously after the first failure.</p>

<tcl>hd_fragment ioerrtesting</tcl>
<h2>I/O Error Testing</h2>

<p>I/O error testing seeks to verify that SQLite responds sanely
to failed I/O operations.  I/O errors might result from a full disk drive,
malfunctioning disk hardware, network outages when using a network
file system, system configuration or permission changes that occur in the
middle of an SQL operation, or other hardware or operating system
malfunctions.  Whatever the cause, it is important that SQLite be able
to respond correctly to these errors and I/O error testing seeks to
verify that it does.</p>

<p>I/O error testing is similar in concept to OOM testing; I/O errors
are simulated and checks are made to verify that SQLite responds
correctly to the simulated errors.  I/O errors are simulated in both

new behavior are retained and further mutated.  In this way, AFL is able
to "discover" new behaviors of the program under test, including behaviors
that were never envisioned by the designers.

<p>AFL proved adept at finding arcane bugs in SQLite.
Most of the findings have been assert() statements where the conditional
was false under obscure circumstances.  But AFL has also found
a fair number of crash bugs in SQLite, and even a few cases where SQLite
computed incorrect results.

<p>Because of its past success, AFL became a standard part of the testing
strategy for SQLite beginning with [version 3.8.10] ([dateof:3.8.10]) until
it was superseded by better fuzzers in [version 3.29.0] ([dateof:3.29.0]).

<tcl>hd_fragment ossfuzz {OSS Fuzz}</tcl>
<h3>Google OSS Fuzz</h3>

<p>Beginning in 2016, a team of engineers at Google started the
[https://github.com/google/oss-fuzz|OSS Fuzz] project.
OSS Fuzz uses a AFL-style guided fuzzer running on Google's infrastructure.
The Fuzzer automatically downloads the latest check-ins for participating
projects, fuzzes them, and sends email to the developers reporting any
problems.  When a fix is checked in, the fuzzer automatically detects this
and emails a confirmation to the developers.

<p>SQLite is one of many open-source projects that OSS Fuzz tests. The

[https://www.sqlite.org/src/timeline?y=ci&c=0a2eb949f8a759e5|[2]]
[https://www.sqlite.org/src/timeline?y=ci&c=62f2235adf796c72|[3]].

<tcl>hd_fragment dbsqlfuzz {dbsqlfuzz}</tcl>
<h3>The dbsqlfuzz fuzzer</h3>

<p>Beginning in late 2018, SQLite has been fuzzed using a proprietary
fuzzer called "dbsqlfuzz".  Dbsqlfuzz is built using the
[http://llvm.org/docs/LibFuzzer.html|libFuzzer] framework of LLVM.

<p>The dbsqlfuzz fuzzer mutates both the SQL input and the database file
at the same time.  Dbsqlfuzz uses a custom
[https://github.com/google/fuzzing/blob/master/docs/structure-aware-fuzzing.md|Structure-Aware Mutator]
on a specialized input file that defines both an input database and SQL
text to be run against that database. Because it mutates both the input
database and the input SQL at the same time, dbsqlfuzz has been able to
find some obscure faults in SQLite that were missed by prior fuzzers that
mutated only SQL inputs or only the database file.
The SQLite developers keep dbsqlfuzz running against trunk in about
16 cores at all times.  Each instance of dbsqlfuzz program is able to
evalutes about 400 test cases per second, meaning that about 500 million
cases are checked every day.</p>

<p>The dbsqlfuzz fuzzer has been very successful at hardening the
SQLite code base against malicious attack.  Since dbsqlfuzz has been
added to the SQLite internal test suite, bug reports from external
fuzzers such as OSSFuzz have all but stopped.

and they do occasionally get bug reports found by independent
fuzzers.  All such reports are promptly fixed, so the product is
improved and that the entire SQLite user community benefits.
This mechanism of having many independent testers is similar to
[https://en.wikipedia.org/wiki/Linus%27s_law|Linus's law]:
"given enough eyeballs, all bugs are shallow".

<p>One fuzzing researcher of particular note is
<a href="https://www.manuelrigger.at/">Manuel Rigger</a>, currently
(as this paragraph is written on 2019-12-21)
at <a href="https://ethz.ch/en.html">ETH Zurich</a>.
Most fuzzers only look for assertion faults, crashes, undefined behavior (UB),
or other easily detected anomalies.  Dr. Rigger's fuzzers, on the other hand,
are able to find cases where SQLite computes an incorrect answer.
Rigger has found

collected in a set of database files in the main SQLite source tree
and then rerun by the "fuzzcheck" utility program whenever one runs
"make test".  Fuzzcheck only runs a few thousand "interesting" cases
out of the billions of cases that the various fuzzers have
examined over the years.  "Interesting" cases are cases that exhibit
previously unseen behavior.  Actual bugs found by fuzzers are always
included among the interesting test cases, but most of the cases run
by fuzzcheck were never actual bugs.

<tcl>hd_fragment tension {coverage testing vs. fuzz testing}</tcl>
<h3>Tension Between Fuzz Testing And 100% MC/DC Testing</h3>

<p>Fuzz testing and [MC/DC|100% MC/DC testing] are in tension with
one another.
That is to say, code tested to 100% MC/DC will tend to be
more vulnerable to problems found by fuzzing and code that performs
well during fuzz testing will tend to have (much) less than
100% MC/DC.
This is because MC/DC testing discourages [defensive code] with
unreachable branches, but without defensive code, a fuzzer is
more likely to find a path that causes problems.  MC/DC testing
seems to work well for building code that is robust during
normal use, whereas fuzz testing is good for building code that is
robust against malicious attack.

<p>Of course, users would prefer code that is both robust in normal
use and resistant to malicious attack.  The SQLite developers are
dedicated to providing that.  The purpose of this section is merely
to point out that doing both at the same time is difficult.

<p>For much of its history SQLite has been focused on 100% MC/DC testing.
Resistance to fuzzing attacks only became a concern with the introduction
of AFL in 2014.  For a while there, fuzzers were finding many problems
in SQLite.  In more recent years, the testing strategy of SQLite has
evolved to place more emphasis on fuzz testing.  We still maintain
100% MC/DC of the core SQLite code, but most testing CPU cycles are
now devoted to fuzzing.

<p>While fuzz testing and 100% MC/DC testing are in tension, they
are not completely at cross-purposes.  The fact that the SQlite test
suite does test to 100% MC/DC means that when fuzzers do find problems,
those problems can be fixed quickly and with little risk of introducing
new errors.

<p>The [dbsqlfuzz] fuzzer also does an excellent job of verifying
that SQLite responds sanely to malformed database files.</p>

<h2>Boundary Value Tests</h2>

<p>SQLite defines certain [limits] on its operation, such as the
maximum number of columns in a table, the maximum length of an
SQL statement, or the maximum value of an integer.  The TCL and TH3 test
suites both contains numerous tests that push SQLite right to the edge
of its defined limits and verify that it performs correctly for
all allowed values.  Additional tests go beyond the defined limits
and verify that SQLite correctly returns errors.  The source code
contains [testcase macros] to verify that both sides of each boundary
have been tested.</p>

<tcl>hd_fragment regressiontesting</tcl>
<h1>Regression Testing</h1>

<p>Whenever a bug is reported against SQLite, that bug is not considered
fixed until new test cases that would exhibit the bug have been added
to either the TCL or TH3 test suites.
Over the years,
this has resulted in thousands and thousands of new tests.
These regression tests ensure that bugs that have
been fixed in the past are not reintroduced into future versions of
SQLite.</p>

test coverage - 100% branch test coverage.</p>

<tcl>hd_fragment defcode {defensive code}</tcl>
<h2>Coverage testing of defensive code</h2>

<p>A well-written C program will typically contain some defensive
conditionals which in practice are always true or always false.
This leads to a
programming dilemma:  Does one remove defensive code in order to obtain
100% branch coverage?</p>

<p>In SQLite, the answer to the previous question is "no".
For testing purposes, the SQLite source code defines
macros called ALWAYS() and NEVER().   The ALWAYS() macro
surrounds conditions

<tt>testcase()</tt> macro is a no-op:</p>

<codeblock>
#define testcase(X)
</codeblock>

<p>But in a coverage measuring build, the <tt>testcase()</tt> macro
generates code that evaluates the conditional expression in its argument.
Then during analysis, a check
is made to ensure tests exist that evaluate the conditional to both true
and false.  <tt>Testcase()</tt> macros are used, for example, to help verify
that boundary values are tested.  For example:</p>

<codeblock>
testcase( a==b );

  /* ... */
}
</codeblock>

<p>For bitmask tests, <tt>testcase()</tt> macros are used to verify that every
bit of the bitmask affects the outcome.  For example, in the following block
of code, the condition is true if the mask contains either of two bits
indicating either a MAIN_DB or a TEMP_DB is being opened.
The <tt>testcase()</tt>
macros that precede the if statement verify that both cases are tested:</p>

<codeblock>
testcase( mask & SQLITE_OPEN_MAIN_DB );
testcase( mask & SQLITE_OPEN_TEMP_DB );
if( (mask & (SQLITE_OPEN_MAIN_DB|SQLITE_OPEN_TEMP_DB))!=0 ){ ... }
</codeblock>

<p>The SQLite source code contains <tcl>N {$stat(nTestcase)}</tcl>
uses of the <tt>testcase()</tt> macro.</p>

<tcl>hd_fragment {mcdc} *MC/DC {MC/DC testing}</tcl>
<h2>Branch coverage versus MC/DC</h2>

<p>Two methods of measuring test coverage were described above:
"statement" and "branch" coverage.  There are many other test coverage
metrics besides these two.  Another popular metric is "Modified
Condition/Decision Coverage" or MC/DC.
[http://en.wikipedia.org/wiki/Modified_Condition/Decision_Coverage | Wikipedia]
defines MC/DC as follows:</p>

<ul>
<li> Each decision tries every possible outcome.
<li> Each condition in a decision takes on every possible outcome.
<li> Each entry and exit point is invoked.
<li> Each condition in a decision is shown to independently
     affect the outcome of the decision.
</ul>

<p>In the C programming language
where <b><tt>&amp;&amp;</tt></b> and <b><tt>||</tt></b>
are "short-circuit" operators, MC/DC and branch coverage are very nearly
the same thing.  The primary difference is in boolean vector tests.
One can test for any of several bits in bit-vector and still obtain
100% branch test coverage even though the second element of MC/DC - the
requirement that each condition in a decision take on every possible outcome -
might not be satisfied.</p>

<p>SQLite uses <tt>testcase()</tt> macros as described in the previous
subsection to make sure that every condition in a bit-vector decision takes
on every possible outcome.  In this way, SQLite also achieves 100% MC/DC
in addition to 100% branch coverage.</p>

<h2>Measuring branch coverage</h2>

<p>Branch coverage in SQLite is currently measured
using [https://gcc.gnu.org/onlinedocs/gcc/Gcov.html|gcov] with the "-b"
option.  First the test program is compiled using options
"-g -fprofile-arcs -ftest-coverage" and then the test program is run.
Then "gcov -b" is run to generate a coverage report.
The coverage report is verbose and inconvenient to read,
so the gcov-generated report is processed using
some simple scripts to put it into a more human-friendly format.
This entire process is automated using scripts, of course.

<p>Note that running SQLite with gcov is not a test of SQLite &mdash;
it is a test of the test suite.  The gcov run does not test SQLite because
the -fprofile-args and -ftest-coverage options cause the compiler to
generate different code.
The gcov run merely verifies that the test suite provides 100% branch test
coverage.  The gcov run is a test of the test - a meta-test.

<p>After gcov has been run to verify 100% branch test coverage,
then the test program is recompiled using delivery compiler options
(without the special -fprofile-arcs and -ftest-coverage options)
and the test program is rerun.
This second run is the actual test of SQLite.

<p>It is important to verify that the gcov test run
and the second real test run both give the same output.  Any
differences in output indicate either the use of undefined or
indeterminate behavior in the SQLite code (and hence a bug),
or a bug in the compiler.
Note that SQLite has, over the previous decade, encountered bugs
in each of GCC, Clang, and MSVC.  Compiler bugs, while rare, do happen,
which is why it is so important to test the code in an as-delivered
configuration.

<tcl>hd_fragment mutationtests {mutation testing}</tcl>
<h2>Mutation testing</h2>

<p>Using gcov (or similar) to show that every branch instruction is taken
at least once in both directions is good measure of test suite quality.
But even better is showing that every branch instruction makes
a difference in the output.  In other words, we want to show
not only that every branch instruction both jumps and falls through but also
that every branch is doing useful work and that the test suite is able
to detect and verify that work.  When a branch is found that does not
make a difference in the output, that suggests that the code associated
the branch can be removed (reducing the size of the library and perhaps
making it run faster) or that the test suite is inadequately testing the
feature that the branch implements.

<p>SQLite strives to verify that every branch instruction makes a difference
using [https://en.wikipedia.org/wiki/Mutation_testing|mutation testing].
[mutation test script|A script]
first compiles the SQLite source code into assembly language
(using, for example, the -S option to gcc).  Then the script steps through
the generated assembly language and, one by one, changes each branch
instruction into either an unconditional jump or a no-op, compiles the
result, and verifies that the test suite catches the mutation.

<p>
Unfortunately, SQLite contains many branch instructions that
help the code run faster without changing the output.
Such branches generate false-positives during mutation testing.
As an example, consider the following
[https://www.sqlite.org/src/artifact/55b5fb474?ln=55-62 | hash function]
used to accelerate table-name lookup:

<codeblock>
55  static unsigned int strHash(const char *z){
56    unsigned int h = 0;
57    unsigned char c;

If the branch instruction that implements the "c!=0" test on line 58
is changed into a no-op, then the while-loop will loop forever and the
test suite will fail with a time-out.  But if that branch is changed
into an unconditional jump, then the hash function will always return 0.
The problem is that 0 is a valid hash.  A hash function that always
returns 0 still works in the sense that SQLite still always gets the correct
answer.  The table-name hash table degenerates into a linked-list
and so the table-name lookups that occur while parsing SQL statements
might be a little slower, but the end result will be the same.

<p>
To work around this problem, comments of the form
"<code>/*OPTIMIZATION-IF-TRUE*/</code>" and
"<code>/*OPTIMIZATION-IF-FALSE*/</code>" are inserted into the SQLite
source code to tell the mutation testing script to ignore some branch

true.  If the assertion is false, the program prints an error message
and halts.</p>

<p>Assert() macros are disabled by compiling with the NDEBUG macro defined.
In most systems, asserts are enabled by default.  But in SQLite, the
asserts are so numerous and are in such performance critical places, that
the database engine runs about three times slower when asserts are enabled.
Hence, the default (production) build of SQLite disables asserts.
Assert statements are only enabled when SQLite is compiled with the
SQLITE_DEBUG preprocessor macro defined.</p>

<p>See the [The Use Of assert In SQLite|Use Of assert in SQLite] document
for additional information about how SQLite uses assert().</p>

<tcl>hd_fragment valgrind</tcl>
<h2>Valgrind</h2>

<p>[http://valgrind.org/ | Valgrind] is perhaps the most amazing
and useful developer tool in the world.  Valgrind is a simulator - it simulates
an x86 running a Linux binary.  (Ports of Valgrind for platforms other
than Linux are in development, but as of this writing, Valgrind only
works reliably on Linux, which in the opinion of the SQLite developers
means that Linux should be the preferred platform for all software development.)
As Valgrind runs a Linux binary, it looks for all kinds of interesting
errors such as array overruns, reading from uninitialized memory,
stack overflows, memory leaks, and so forth.  Valgrind finds problems
that can easily slip through all of the other tests run against SQLite.
And, when Valgrind does find an error, it can dump the developer directly
into a symbolic debugger at the exact point where the error occur, to
facilitate a quick fix.</p>

<p>Because it is a simulator, running a binary in Valgrind is slower than
running it on native hardware.  (To a first approximation, an application
running in Valgrind on a workstation will perform about the same as it
would running natively on a smartphone.)  So it is impractical to run the full
SQLite test suite through Valgrind.  However, the veryquick tests and
the coverage of the TH3 tests are run through Valgrind prior to every
release.</p>

<tcl>hd_fragment memtesting</tcl>
<h2>Memsys2</h2>

<p>SQLite contains a pluggable
[memory allocation | memory allocation subsystem].
The default implementation uses system malloc() and free().
However, if SQLite is compiled with [SQLITE_MEMDEBUG], an alternative
memory allocation wrapper ([memsys2])
is inserted that looks for memory allocation
errors at run-time.  The memsys2 wrapper checks for memory leaks, of
course, but also looks for buffer overruns, uses of uninitialized memory,
and attempts to use memory after it has been freed.  These same checks
are also done by valgrind (and, indeed, Valgrind does them better)
but memsys2 has the advantage of being much faster than Valgrind, which
means the checks can be done more often and for longer tests.</p>

<tcl>hd_fragment mutextesting</tcl>
<h2>Mutex Asserts</h2>

<p>SQLite contains a pluggable mutex subsystem.  Depending on
compile-time options, the default mutex system contains interfaces
[sqlite3_mutex_held()] and [sqlite3_mutex_notheld()] that detect
whether or not a particular mutex is held by the calling thread.
These two interfaces are used extensively within assert() statements
in SQLite to verify mutexes are held and released at all the right
moments, in order to double-check that SQLite does work correctly
in multi-threaded applications.</p>

<tcl>hd_fragment intoverflow</tcl>
<h2>Undefined Behavior Checks</h2>

<p>In the C programming language, it is very easy to write code that
has "undefined" or "implementation defined" behavior.
That means that the code might work during development, but then give
a different answer on a different system, or when recompiled using different
compiler options.
Examples of undefined and implementation-defined behavior in
ANSI C include:
<ul>
<li>Signed integer overflow.  (Signed integer overflow does <u>not</u>
necessarily wrap around, as most people expect.)
<li>Shifting an N-bit integer by more than N bits.
<li>Shifting by a negative amount.

<p>One verification technique used on SQLite is to run an entire test suite
twice, once with optimizations left on and a second time with optimizations
turned off, and verify that the same output is obtained both times.  This
shows that the optimizations do not introduce errors.</p>

<p>Not all test cases can be handled this way.  Some test cases check
to verify that the optimizations really are reducing the amount of
computation by counting the number of disk accesses, sort operations,
full-scan steps, or other processing steps that occur during queries.
Those test cases will appear to fail when optimizations are disabled.
But the majority of test cases simply check that the correct answer
was obtained, and all of those cases can be run successfully with and
without the optimizations, in order to show that the optimizations do not
cause malfunctions.</p>

<tcl>hd_fragment staticanalysis</tcl>
<h1>Static Analysis</h1>

<p>Static analysis means analyzing source code at compile-time to
check for correctness.  Static analysis includes compiler
warning messages and more in-depth analysis engines such as the
[http://clang-analyzer.llvm.org/ | Clang Static Analyzer].
SQLite compiles without warnings on GCC and Clang using
the -Wall and -Wextra flags on Linux and Mac and on MSVC on Windows.
No valid warnings are generated by the Clang Static Analyzer tool "scan-build"
either (though recent versions of clang seem to generate many false-positives.)
Nevertheless, some warnings might be generated by other
static analyzers.  Users are encouraged not to stress over these
warnings and to instead take solace in the intense testing of SQLite
described above.
</p>

<p>Static analysis has not been helpful in finding
bugs in SQLite.  Static analysis has found a few bugs in SQLite, but
those are the exceptions.  More bugs have been
introduced into SQLite while trying to get it to compile without
warnings than have been found by static analysis.</p>

<tcl>hd_fragment summary</tcl>
<h1>Summary</h1>

<p>SQLite is open source.  This gives many people the idea that
it is not well tested as commercial software and is perhaps unreliable.
But that impression is false.
SQLite has exhibited very high reliability in the field and
a very low defect rate, especially considering how rapidly it is evolving.
The quality of SQLite is achieved in part by careful code design and
implementation.  But extensive testing also plays a vital role in
maintaining and improving the quality of SQLite.  This document has
summarized the testing procedures that every release of SQLite undergoes
with the hope of inspiring confidence that SQLite is
suitable for use in mission-critical applications.</p>

  AND comment NOT LIKE '%andidate%' AND comment NOT LIKE '%withdrawn%'
  AND ht NOT IN ('dde65e9e06','d07b7b67d1','972e75bb5d','917c410808',
  '605907e73a','f139f6f07d','1df5386a55','765359c77e','8467d84fc6',
  '0a8c2f4f98','003f967e87','b0805b6069') -- de-duplication clause
  ORDER BY tstamp DESC;
}

set ::versions_now [list]
set exit_status 0
try {
  rdb eval $tv
  set ::versions_now [rdb eval $vq]
} on error erc {
  puts stderr "View creation or versions query failed."
  set exit_status 1
} finally {
  rdb close
}

if {$exit_status > 0} {exit $exit_status}

set lines_before [list]
array set ::versions_pending [list]
set versions_old [list]
set lines_after [list]
set glom_state 0
set glomee lines_before

set ::versionRe {^[0-9a-f]{10}\|}
set ::pendingRe {^x{6,10}\|[^\|]*\|}
set ::verNumRe {([0-9\.]+) *$}

proc add_pending {line} {
  set vtag [regsub -nocase $::pendingRe $line {}]
  if {![regexp $::verNumRe $vtag _ vn]} {
    puts stderr "Cannot extract version number from: $line"
    exit 1
  }
  incr ::versions_pending($vn)
}

try {
  set ct_fid [open $ct r]
  while {![eof $ct_fid]} {
    if {[gets $ct_fid line] < 0} break
    if {[set line [string trimright $line]] ne ""} {
      set isvl [regexp $::versionRe $line]
      set isvp [regexp -nocase $::pendingRe $line]
      switch $glom_state {
        0 {
          if {$isvp} {add_pending $line; continue}
          if {$isvl} {incr glom_state; set glomee versions_old}
        }
        1 { if {!$isvl} {incr glom_state; set glomee lines_after} }
        2 {}
      }
    }
    lappend $glomee $line
  }
  close $ct_fid
} on error orc {
  puts stderr "Error: Cannot read $ct ."
  exit 1
}
set ::noldver [llength $versions_old]
set ::nnewver [llength $::versions_now]

if {$::nnewver < $::noldver} {
  puts stderr "Error: Versions list is shrinking. No update done."
  exit 1
}

# Do a sanity check on prior or all versions.
for {set io $::noldver; set in $::nnewver} {$io > 0 && $in > 0} {} {
  incr io -1; incr in -1
  if {[lindex $versions_old $io] ne [lindex $::versions_now $in]} {
    puts stderr "Error: Version history appears to be changing. Aborting."
    exit 1
  }
}
set ::revs_count [expr $::nnewver - $::noldver]

proc resolve_pending_new {} {
  set rv [list]
  set ixo [llength $::versions_now]
  for {set ix 0} {$ix < $::revs_count} {incr ix} {
    set vnew [lindex $::versions_now [expr $ix + $::noldver]]
    if {[regexp $::verNumRe $vnew _ vn]} {
      unset -nocomplain $::versions_pending($vn);
    }
  }
  set pvs [lsort [array names ::versions_pending]]
  foreach vn $pvs {
    lappend rv "xxxxxxxxxx|pending|Version $vn"
  }
  if {[array size ::versions_pending] > 0} {
    puts stderr "Still-pending versions: [join $pvs { }]"
  }
  return $rv;
}

if {$::revs_count > 0} {
  if {[array size ::versions_pending] > 0} {
    set vp_left [resolve_pending_new]
  } else { set vp_left [list] }
  try {
    set ct_fid [open $ct w]
    puts $ct_fid [join $lines_before "\n"]
    if {[llength $vp_left] > 0} {
      puts $ct_fid [join $vp_left "\n"]
    }
    puts $ct_fid [join $::versions_now "\n"]
    puts $ct_fid [join $lines_after "\n"]
  } on error owc {
    puts stderr "Error: Cannot write $ct with new version(s). Aborting."
    exit 1
  }
  close $ct_fid
  set post_msg "Source-controlled file \"$ct\" should be checked in."

  lappend files {*}[glob $fgspec]
}

set fcount 0
set rcount 0
array set fstats {}
set killPattern {(\^\()|(\)\^)|\^}
if {!$sayStats} {puts -nonewline {Removing ^( )^ and ^ ...}}
foreach fm $files {
  if {![info exists fstats($fm)]} {
    set ifd [open $fm r]
    set text [regsub -all $killPattern [read $ifd] {}]
    set shrink [expr [file size $fm] - [string length $text]]
    set fstats($fm) $shrink
    close $ifd

#!/usr/bin/tclsh
#
# Run this script to create two database files "docinfo.db" and "history.db"
# with appropriate schemas.
#
package require sqlite3 ;# Needed if run by stock tclsh

sqlite3 db docinfo.db
db eval {
  BEGIN;

  /*
  ** Every page in the documentation set is a row in the following table:
  */
  CREATE TABLE IF NOT EXISTS page(

    srcline INTEGER,         -- line number in source document
    url TEXT,                -- URL & fragment of htmlized evidence
    UNIQUE(srcfile, srcline, srccat)
  );
  CREATE INDEX IF NOT EXISTS ev_reqno ON evidence(reqno);
  COMMIT;
}
set history_db history.db
db eval {
  ATTACH $history_db AS history;
  BEGIN;
  CREATE TABLE IF NOT EXISTS history.allreq(
    reqno TEXT PRIMARY KEY,  -- Ex: R-12345-67890-...
    reqimage BOOLEAN,        -- True for an image requirement
    reqtext TEXT,            -- Normalized text of requirement or image filename

#
#    $doc parsenode HTML
#      Parse return a new node or nodes.
#
# NODE OBJECT API:
#
#    $node tag
#      Get or set the nodes tag type. Always lower-case. Empty string
#      for text.
#
#    $node children
#      Return a list of the nodes children.
#
#    $node text
#      For a text node, return the text. For any other node, return the
#      concatenation of the text belonging to all descendent text nodes
#      (in document order).
#
#    $node parent
#      Return the nodes parent node.
#
#    $node offset
#      Return the byte offset of the node within the document (if any).
#
#    $node foreach_descendent VARNAME SCRIPT
#      Iterate through all nodes in the sub-tree headed by $node. $node
#      itself is not visited.
#
#    $node attr ?-default VALUE? ATTR ?NEWVALUE?
#
#    $node search PATTERN
#      Return a list of descendent nodes that match pattern PATTERN.
#

  variable iNextid 0

  # Ignore all tags in the aIgnore[] array.
  variable aIgnore
  set aIgnore(html) 1
  set aIgnore(/html) 1
  set aIgnore(!doctype) 1

  # All inline tags.
  variable aInline
  foreach x {
    tt i b big small u
    em strong dfn code samp kbd var cite abbr acronym
    a img object br script map q sub sup span bdo
    input select textarea label button tcl yyterm yynonterm

  set aContentChecker(li)       HtmlLiContent
  set aContentChecker(dt)       HtmlLiContent
  set aContentChecker(dd)       HtmlLiContent
  set aContentChecker(dl)       HtmlDlContent

  # Add content checkers for all self-closing tags.
  foreach x {
    area base br hr iframe img input isindex link meta
    param script style embed nextid wbr bgsound
  } {
    set aContentChecker($x) HtmlEmptyContent
    set aSelfClosing($x) 1
  }

  namespace export parse
  namespace ensemble create
}

  upvar $arrayname O
  foreach c $O($id,children) { create_node_command $arrayname $c }
  return $O($id,children)
}

proc ::hdom::foreach_desc {arrayname id varname script level} {
  upvar $arrayname O
  foreach c $O($id,children) {
    create_node_command $arrayname $c
    uplevel $level [list set $varname $c]

    set rc [catch { uplevel $level $script } msg info]
    if {$rc == 0 || $rc == 4} {
      # TCL_OK or TCL_CONTINUE Do nothing
    } elseif {$rc == 3} {

# Node method [$node offset]
#
proc ::hdom::nm_offset {arrayname id} {
  upvar $arrayname O
  return $O($id,offset)
}

# Node method: $node attr ?-default VALUE? ?ATTR?
#
#   $node attr
#   $node attr ATTR
#   $node attr ATTR NEWVALUE
#   $node attr -default VALUE ATTR
#
proc ::hdom::nm_attr {arrayname id args} {

  if {$P!=""} {
    set idx [lsearch $O($P,children) $id]
    if {$idx<0} {error "internal error!"}
    set O($P,children) [lreplace $O($P,children) $idx $idx]
  }
}

# Node method:
#
#   $node addChild CHILD
#   $node addChild -before BEFORE CHILD
#
proc ::hdom::nm_addChild {arrayname id args} {
  upvar $arrayname O

    set newidx [lsearch $O($id,children) $before]
    if {$newidx < 0 } {error "$before is not a child of $id"}
    set newchild [lindex $args 2]
  }

  # Unlink $newchild from its parent:
  $newchild detach

  # Link $newchild to new parent ($id):
  set O($id,children) [linsert $O($id,children) $newidx $newchild]
  set O($newchild,parent) $id
}

# Document method [$doc root]
#

  #
  set O(current) $root
  set O(root) $root
  set O(cmdlist) [list]

  parsehtml $html [list parsehtml_cb O]

  # Create the document object command.
  #
  proc $doc {method args} [subst -nocommands {
    uplevel ::hdom::document_method $doc [set method] [set args]
  }]
  return $doc
}

    while( *z && *z!='<' ) z++;

    /* Invoke the callback script for the chunk of text just parsed. */
    rc = doTextCallback(interp,aCall,nElem,zText,z-zText,zText-zHtml,z-zHtml);
    if( rc!=TCL_OK ) return rc;

    /* Unless is at the end of the document, z now points to the start of a
    ** markup tag. Either an opening or a closing tag. Parse it up and
    ** invoke the callback script. */
    if( *z ){
      int nTag;
      char *zTag;
      int iOffset;                /* Offset of open tag (the '<' character) */

      assert( *z=='<' );
      iOffset = z - zHtml;
      z++;
      if( *z && 0==strncmp("!--", z, 3) ){
        while( *z && strncmp("-->", z, 3 ) ) z++;
        z += 3;
        continue;
      }
      while( ISSPACE(*z) ) z++;
      zTag = z;

      while( *z && !ISSPACE(*z) && *z!='>' ) z++;
      nTag = z-zTag;

      if( nTag==5 && 0==strncasecmp("style", zTag, 5) ){
        while( *z && strncasecmp("/style>", z, 7 ) ) z++;
        z += 7;
        continue;
      } else if( nTag>=6 && 0==memcmp("script", zTag, 6) ){
        while( *z && strncasecmp("/script>", z, 8 ) ) z++;
        z += 8;
        continue;
      } else if( nTag>=3 && 0==memcmp("svg", zTag, 3) ){
        /* Special cases:
        ** parse <svg>...</svg> as if it were a single big block of text.
        ** This allows the geopoly.html document to be rendered correctly,
        ** and allows the search indexes to be computed in a reasonable
        ** amount of time.
        */

              nVal = z-zVal;
            }
            Tcl_ListObjAppendElement(interp,pParam,Tcl_NewStringObj(zVal,nVal));
          }else if( zAttr ){
            Tcl_ListObjAppendElement(interp, pParam, Tcl_NewIntObj(1));
          }
        }

        rc = doTagCallback(interp,
            aCall, nElem, zTag, nTag, iOffset, 1+z-zHtml, pParam
        );
        if( rc!=TCL_OK ) return rc;

        if( nTag==3 && memcmp(zTag, "tcl", 3)==0 ){
          const char *zText = &z[1];
          while( *z && strncasecmp("</tcl>", z, 6) ) z++;

/*
** 2022 December 31
**
** The author disclaims copyright to this source code.  In place of
** a legal notice, here is a blessing:
**
**    May you do good and not evil.
**    May you find forgiveness for yourself and forgive others.
**    May you share freely, never taking more than you give.
**
*************************************************************************
** This file implements a URL checker. See zUsage below for operation.
** It should compile on Linux systems having a certain Curl library.
**   apt install libcurl4-openssl-dev
** Build executable thusly:
**   gcc urlcheck.c -Os -o urlcheck -lcurl
*/

const char *zUsage = "\
Usage: urlcheck [<options>] [<urls>]|[--help]\n\
If URL arguments are provided, they are checked for HTTP server responses.\n\
If no URLs are provided, URLs are read 1 per line from stdin and checked.\n\
Output is bar-separated 3-tuple lines of URL, response_code, code_as_text.\n\
Option --ok-silent suppresses output for URLs yielding an HTTP 200 response.\n\
";
#include <stdio.h>
#include <stdlib.h>
#ifdef __STDC_ALLOC_LIB__
#define __STDC_WANT_LIB_EXT2__ 1
#else
#define _POSIX_C_SOURCE 200809L
#endif
#include <string.h>
#include <curl/curl.h>

typedef struct XfrStatus {
  int iStatus;
  size_t nAlloc;
  char *zText;
} XfrStatus;

static size_t header_sift(char *buf, size_t sz, size_t ni, void *pv){
  XfrStatus *pxs = (XfrStatus *)pv;
  if( ni>6 && strncmp(buf, "HTTP", 4) == 0 ){
    int respcode = 0, i;
    int nr = 0;
    char c = buf[ni-1], cjunk;
    buf[ni-1] = 0;
    for( i=4; i<ni; ++i){
      if( buf[i] == ' ' ) break;
    }
    if( 2 == sscanf(buf+i, "%d%c%n", &respcode, &cjunk, &nr) ){
      pxs->iStatus = respcode;
      if( pxs->zText != 0 ) free(pxs->zText);
      pxs->zText = strdup( &buf[i+nr] );
    }
    buf[ni-1] = c;
  }
  return sz * ni;
}

void one_url( CURL *pCurl, char *zUrl, XfrStatus *pxs, int okhush){
  CURLcode crc;
  curl_easy_setopt(pCurl, CURLOPT_URL, zUrl);
  pxs->iStatus = 0;
  if( CURLE_OK != (crc = curl_easy_perform(pCurl)) ){
    fprintf(stdout, "%s|%d|%s\n", zUrl, -1, curl_easy_strerror(crc));
  }else{
    char *zRS = pxs->zText;
    if( zRS == 0 ) zRS = "?";
    else if( *zRS < ' ' ){
      switch( pxs->iStatus ){
      case 200: zRS = "OK"; break;
      case 404: zRS = "Not Found"; break;
      default: zRS = "?";
      }
    }
    if( !okhush || pxs->iStatus != 200 ){
      fprintf(stdout, "%s|%d|%s\n", zUrl, pxs->iStatus, zRS);
    }
  }
  if( pxs->zText != 0 ){
    free(pxs->zText);
    pxs->zText = 0;
  }
}

int main(int na, char **av){
  int ok_silent = 0;
  XfrStatus xs = { 0, 0, 0 };
  int aix;
  CURL *pCurl = curl_easy_init();

  if( na>=2 && 0==strcmp(av[1], "--ok-silent") ){
    ok_silent = 1;
    --na; ++av;
  }

  curl_easy_setopt(pCurl, CURLOPT_USERAGENT, "libcurl-agent/1.0");
  curl_easy_setopt(pCurl, CURLOPT_FOLLOWLOCATION, 1);
  curl_easy_setopt(pCurl, CURLOPT_NOPROGRESS, 1);
  curl_easy_setopt(pCurl, CURLOPT_TIMEOUT_MS, 5000L);
  curl_easy_setopt(pCurl, CURLOPT_SSL_VERIFYHOST, 0);
  curl_easy_setopt(pCurl, CURLOPT_SSL_VERIFYPEER, 0);
  curl_easy_setopt(pCurl, CURLOPT_NOBODY, 1);
  curl_easy_setopt(pCurl, CURLOPT_HEADERDATA, &xs);
  curl_easy_setopt(pCurl, CURLOPT_HEADERFUNCTION, header_sift);
  if( na < 2 ){
    char lbuf[1000];
    while( 0 != fgets(lbuf, sizeof(lbuf), stdin) ){
      int nbi, nbe;
      for( nbi=0; nbi<sizeof(lbuf) && lbuf[nbi]; ++nbi )
        if( lbuf[nbi]!=' ' ) break;
      for( nbe=nbi; nbe<sizeof(lbuf) && lbuf[nbe]; ++nbe )
        if( lbuf[nbe]==' ' || lbuf[nbe] == '\n' ) break;
      if( nbi==sizeof(lbuf) || nbe==nbi ) continue;
      lbuf[nbe--] = 0;
      if( nbe==nbi ) continue;
      one_url( pCurl, &lbuf[nbi], &xs, ok_silent );
    }
  }else{
    if( na==2 && strcmp(av[1],"--help")==0 ){
      fprintf(stdout, "%s", zUsage);
    }else{
      for( aix=1; aix < na; ++aix ){
        one_url( pCurl, av[aix], &xs, ok_silent );
      }
    }
  }
  curl_easy_cleanup(pCurl);
  return 0;
}