Documentation Source Text

  global inrow body rowbody rowtag keyword dflt_parent
  if {$inrow} {
    set rowbody [string trim $rowbody]
    append body $rowbody</td></tr>\n
    if {$dflt_parent!=""} {
      append rowbody " <$dflt_parent>"
    }
    #hd_requirement $rowtag $rowbody
    #set keyword($rowtag) 1
    set inrow 0
    set rowbody {}
    set rowtag {}
  }
}
proc endtab {} {
  global intab body

      set reqdf {}
      if {[regexp {\{([AHLS]\d\d\d\d\d)\}} $title all reqtag]} {
        regsub { *\{[AHLS]\d\d\d\d\d\}} $title {} title
        while {[regexp {<([AHLS]\d\d\d\d\d)>} $title all df]} {
          append reqdf <$df>
          regsub { *<[AHLS]\d\d\d\d\d>} $title {} title
        }
        # set keyword($reqtag) 1
      }
      set kwlist [lsort [array names keyword]]
      unset -nocomplain keyword
      if {$exflag} {
        foreach kw $kwlist {set supported($kw) 1}
      } elseif {$obsflag} {
        foreach kw $kwlist {set supported($kw) 2}
      } else {
        foreach kw $kwlist {set supported($kw) 0}
      }
      set exflag 0
      set obsflag 0
      set key $type:$kwlist
      regsub -all { *\{[\w.]+\}} $body {} body
      set body [string map \
          {<todo> {<font color="red">(TODO: } </todo> )</font>} $body]
      set code [string map {& &amp; < &lt; > &gt;} $code]
      lappend content [list $key $title $type $kwlist $body $code]
      #if {$reqtag!=""} {
      #  set reqbody "The sqlite3.h header file shall define the\n"
      #  append reqbody "the following interfaces:\n<blockquote><pre>\n"
      #  append reqbody $code
      #  append reqbody "\n</pre></blockquote>"
      #  #hd_requirement $reqtag $reqbody$reqdf 1

      #}
      set title {}
      set keywords {}
      set type {}
      set body {}
      set code {}
      set phase 0
      set dcnt 0

      <a href="http://www.sqlite.org/cvstrac/timeline">
      http://www.sqlite.org/cvstrac/timeline</a>.</p>
    }
    hd_close_aux
    hd_enable_main 1
  }
}

chng {2008 Dec 18 (3.6.7)} {
<li>Reorganize the Unix interface in os_unix.c</li>
<li>Added support for "Proxy Locking" on MacOSX.</li>
<li>Changed the prototype of the [sqlite3_auto_extension()] interface in a
    way that is backwards compatible but which might cause warnings in new
    builds of applications that use that interface.</li>
<li>Changed the signature of the xDlSym method of the [sqlite3_vfs] object
    in a way that is backwards compatible but which might cause warnings.</li>
}

chng {2008 Nov 26 (3.6.6.2)} {
<li>Fix a bug in the b-tree delete algorithm that seems like it might be
    able to cause database corruption.  The bug was first introduced in
    [version 3.6.6] by check-in &#91;5899&#93; on 2008-11-13.</li>
<li>Fix a memory leak that can occur following a disk I/O error.</li>
}

    For example, execution of a single "UPDATE" statement may result in 
    many entries being removed and inserted into a table B-Tree and several
    index B-Trees. 
  <p>
    The list of operations above itemizes inserting and removing entries 
    from index and table B-Trees separately. Requirements specifying the
    set of database file operations required by various SQL statements
    may be found in <i>insert-link</i>. 
    The requirements in <i>insert-link</i> are written so as to
    ensure that the constraints relating the content of a table B-Tree and 
    its associated index B-Trees are met (see section YYY). By contrast the
    requirements specifying the behaviour of the system when a 
    schema item (table, index, view or trigger) is added to or removed 
    from a database describe both the schema (sqlite_master) table
    modifications and any additional modifications made to other parts
    of the database file.

    <tr><td style="width:5ex" id="capi_sqlitert_requirements">[3]<td>
      C API Requirements Document.
    <tr><td style="width:5ex" id="sql_sqlitert_requirements">[4]<td>
      SQL Requirements Document.
    <tr><td style="width:5ex" id="io_sqlitert_requirements">[5]<td>
      File IO Requirements Document.
  </table>

<tcl>
proc hd_assumption {id text} {
  # hd_requirement $id $text
}

proc process {text} {
  set zOut ""
  set zSpecial ""

  foreach zLine [split $text "\n"] {

        regexp { *ASSUMPTION *([^ ]+) *} $zLine -> zRecid
        append zOut "<p class=req id=$zRecid>"
        set zSpecial hd_assumption
        set zRecText ""
      }
      {^ *$} {
        if {$zSpecial ne ""} {
          # $zSpecial $zRecid $zRecText
          set zSpecial ""
          append zOut </p>
        }
      }
      default {
        if {$zSpecial ne ""} {
          if {[regexp {^ *\. *$} $zLine]} {set zLine ""}

      C API Requirements Document.
    <tr><td style="width:5ex" id="sql_sqlitert_requirements">[2]<td>
      SQL Requirements Document.
    <tr><td style="width:5ex" id="ff_sqlitert_requirements">[3]<td>
      File Format Requirements Document.
  </table>
}]</tcl>

<title>Requirements Derivation Matrix</title>

<tcl>
# Read all of the requirements content out of the "req" folder
#
unset -nocomplain REQMATRIX
foreach file [lsort [glob $::DOC/req/*.txt]] {
  hd_read_requirement_file $file REQMATRIX
}
</tcl>

<h2>Requirements Derivation Matrix</h2>

<table cellspacing="20">
<tcl>
unset -nocomplain REQMATRIX_CHILDREN
foreach id $REQMATRIX(*) {set REQMATRIX_CHILDREN($id) {}}
foreach id $REQMATRIX(*) {
  foreach pid [lindex $REQMATRIX($id) 0] {
    lappend REQMATRIX_CHILDREN($pid) $id
  }
} 
foreach id $REQMATRIX(*) {
  if {[string index $id 0]=="A"} continue
  hd_puts "\n<tr>\n"
  hd_puts "<td valign=\"top\"><a name=\"$id\">$id</a></td>\n"

  hd_puts "<td valign=\"top\">\n"

  hd_resolve [lindex $REQMATRIX($id) 1]

  hd_puts \n<p>
  set plist [lindex $REQMATRIX($id) 0]
  if {[llength $plist]==0} {
    hd_puts "<i>No parents</i>"
  } else {
    hd_puts "Parents:"
    foreach pid $plist {
      hd_puts " <a href=\"#$pid\">$pid</a>\n"
    }
  }
  hd_puts </p>\n<p>
  set clist $REQMATRIX_CHILDREN($id)
  if {[llength $clist]==0} {
    hd_puts "<i>No children</i>"
  } else {
    hd_puts "Children:"
    foreach cid $clist {
      hd_puts " <a href=\"#$cid\">$cid</a>\n"
    }
  }
  hd_puts </p>\n
  hd_puts "</td></tr>\n"
}
</tcl>
</table>

<title>SQLite Requirements</title>

<h1>SQLite Requirements</h1>

<h2>1.0 Introduction</h2>

<p>These requirements strive to describe the interfaces and operation of 
SQLite in sufficient detail that a compatible implementation of SQLite
can be written solely from these requirements and without reference to
the canonical SQLite source code.</p>

<p>Software development processes typically recognize a hierarchy of
requirements:</p>

<ul>
<li>System requirements</li>
<li>High-level requirements</li>
<li>Derived high-level requirements</li>
<li>Low-level requirements</li>
<li>Derived low-level requirements</li>
</ul>

<p>The usual distinction between high-level and low-level requirements is
that high-level requirements describe "what" the system does and the
low-level requirements describe "how" the system does it.  Since the
the requirements denoted here describe the
behavior of SQLite and not its implementation, they are best thought of
as high-level requirements.  Consistent with that view, most of
the requirements numbers begin with the letter "<b>H</b>" (for "high-level"). 
A few of the requirements presented here specify broad objectives that
SQLite strives to achieve.  These broad requirements can be thought of
as system requirements and are number with an initial letter "<b>S</b>".</p>

<p>These requirements are hierarchical in the sense that the more
specific requirements are derived from broader and more general
requirements.  When requirement B is derived from requirement A, we say
that A is the parent of B and that B is a child of A.  The parent/child
relationships of all requirements are tracked.  All requirements presented
here ultimately derive from a single very broad, very high-level, and
very general system requirement called "S10000".</p>

<p>Some behaviors of SQLite are undefined.  For example, the order in
which result rows are returned from a SELECT statement is undefined if
there is no ORDER BY clause.  As another example, many of the C interfaces
require a pointer to an open [database connection] as their first argument
and the behavior of those interfaces is undefined (and probably undesirable)
if a pointer to some other object is supplied instead.  Some, but not all
undefined behaviors are explicitly stated and number in this document
with numbers beginning with the "<b>U</b>" for "Undefined".  Applications
that use SQLite should never depend on undefined behavior.  If a behavior
is not explicitly defined by a requirement, then the behavior is undefined,
and so explicitly stating undefined behaviors in this document is
technically redundant.  Nevertheless, we find that explicitly stating
some undefined behaviors helps application developers to better understand
the boundaries of operation of SQLite and to generate safer and more
accurate programs that use SQLite.</p>

<h2><a href="sysreq.html">2.0 System Requirements</a></h2>

<h2><a href="hlr10000.html">3.0 Application C-Language Interfaces</a></h2>

<h2><a href="hlr20000.html">4.0 C-Language Interfaces For
Extending SQLite</a></h2>

<h2><a href="hlr30000.html">5.0 Database File Format</a></h2>

<h2><a href="hlr40000.html">6.0 SQL Language Specification</a></h2>

<title>SQLite System Requirements</title>




















<h1>System Requirements For SQLite</h1>

<p>This document outlines the chief goals and objectives of the SQLite

library. All of the features and capabilities of SQLite (that is to say,
<a href="requirements.html">all requirements</a> of SQLite) can 
ultimately be traced back to one of the broad and general
requirements specified here.</p>

<p>SQLite is not a complete system and so the requirements
provided by this document are not system requirements in the
strict sense.  Perhaps "sub-system requirements" would be a better
term, since SQLite is always a sub-component of a larger system.</p>

<p>This document is targeted primarily at developers who are
working within a waterfall development model that uses detailed
requirements written with the modal auxiliary verb "shall".  
However, this document is also useful as a general-purpose high-level 
description of SQLite for developers who are not working under
different development paradigms.</p>


<dl>
<tcl>










# Actual requirements text is stored separately.  Read and render it.







#

















































































unset -nocomplain SYSREQ
hd_read_requirement_file $::DOC/req/asysreq.txt SYSREQ










foreach id $SYSREQ(*) {









































































  hd_puts "\n<dt><b>"











  hd_fragment $id $id











  hd_puts "$id</b></dt>\n"

















  hd_puts "<dd><p>\n"








































  hd_resolve [lindex $SYSREQ($id) 1]\n















  set comment [lindex $SYSREQ($id) 2]

















  if {$comment!=""} {













    hd_puts "</p>\n<p>"













    hd_resolve $comment\n


























  }


























































































































































































































































































































































  hd_puts "</p></dd>\n"
}
</tcl>










</dl>

SYSREQ S10000 
The SQLite library shall translate high-level SQL statements into
low-level I/O calls to persistent storage.

  SQLite is an SQL database engine.  And the fundamental task of
  every SQL database engine it to translate the abstract SQL statements
  readily understood by humans into sequences of I/O operations readily
  understood by computer hardware.  This requirement expresses the
  essense of SQLite.


SYSREQ S10100 S10000
The SQLite library shall accepts a well-defined dialect of SQL
that conforms to published SQL standards.

  SQL is one of the worlds most widely known programming languages,
  but it is also one of the most ill-defined.  There are various SQL
  standards documents available.  However the SQL standards documents are 
  obtuse to the point of being incomprehensible.  And the standards 
  allow for so much "implementation defined" behavior that there exist
  two SQL database engines understand exactly the same language.</p>
  
  <p>SQLite does not attempt to obtain strict compliance with any
  one of the various SQL standards.
  Instead, SQLite tries to be as compatible as possible with other SQL
  database engines.  SQLite attempts to operate on the principle of
  least surprise.  That is to say, experienced SQL programmers should
  find SQLite's dialect intuitive and natural.</p>
  
  <p>SQLite may omit some obscure features of SQL.  And the SQL
  dialect that SQLite understands might contain some enhancements not
  found in some standards documents.  Nevertheless, applications
  written for other SQL database engines should be portable to SQLite
  with little to no change.  And programmers writing code for SQLite
  should not encounter anything unexpected.

SYSREQ S10110 S10100
The SQLite library shall support BLOB, CLOB, integer, and floating-point
datatypes.

SYSREQ S10120 S10100
The SQLite library shall implement the standard SQL interpretation
of NULL values.

  In cases where
  published standards are ambiguous, SQLite will follow the practice of
  other popular database engines.

SYSREQ S10200 S10000
The SQLite library shall communicate directly with database files
in persistent storage.

  Most other database
  engines implement a client/server model in which a small client library
  is linked with the application and the client communicates with a separate
  server process using interprocess communication (IPC).  SQLite avoids
  the complication of having a separate server process by doing direct
  I/O directly to the underlying filesystem.

SYSREQ S10300 S10000
The SQLite library shall implement ACID transactions.

  In the database world, "ACID" is an acronym for Atomic, Consistent,
  Isolated, and Durable.  Atomic means that a change to the database
  happens either entirely or not at all.  Consistent means that if the
  database file is well-formed before the start of a transaction then
  it is guaranteed to be well-formed after the transaction commits.  
  Isolated means that when two or more threads are
  processes are working with the same database, uncommitted changes 
  made by one are not visible to the other.  Durable means that once
  a transaction commits, it stays committed even if there is a subsequent
  software crash or power failure.

SYSREQ S10500 S10000
The SQLite library shall implement transactions that are robust
across application crashes, operating-system crashes, and power
failures.

  An operating system crash or an unexpected power loss can
  sometimes damage
  the underlying persistent storage in ways that no software can defend
  against.  (For example, the content of a disk drive might be completely
  erased and become unrecoverable.)
  Nevertheless, software can take steps to defend against the kinds
  of damage that typically occurs following operating system crashes and 
  power failures.  The usual damage is that some writes are missing
  or incomplete and that writes have occurred out of order.  We say
  that software is "robust" if it defines against the common kinds of
  damage seen following an operating system crash or power loss.</p>


SYSREQ S10600 S10000
The SQLite library shall support simultaneous access to multiple
database files on the same database connection.

  Many applications benefit from being about to access multiple
  database file using the same database connection, so that 
  information can be transfered from from one database to another 
  atomically, or so that queries can join data across multiple
  databases.

SYSREQ S10700 S10000
The SQLite library shall provide interfaces that allow the application
to obtain the status and results of SQL operations.

SYSREQ S20000 
The SQLite library shall be extensible and configurable.

  SQLite is intended to be an embedded database that functions well
  in resource-limited systems.  For that reason we desire to keep the
  size of the library small.  That choices argues against a large
  default function set.  Instead of having many built-in features, SQLite is
  designed to be extensible at compile-time and run-time with new
  application-defined functions and behaviors.

SYSREQ S20100 S20000
The SQLite library shall provide interfaces that permit the application
to override interfaces to the platform on which the application is running.

  SQLite works on common workstations and in embedded systems.
  Sometimes these devices, particularly embedded systems,
  have odd and unusual operating systems.  In order to support
  this level of portability, SQLite allows the interface to the operating
  system to be defined at run-time.

SYSREQ S20110 S20100
The SQLite library shall provide interfaces that permit the application
to override the interfaces used to read and write persistent storage.

SYSREQ S20120 S20100
The SQLite library shall provide interfaces that permit the application
to override the interfaces used for memory allocation.

SYSREQ S20130 S20100
The SQLite library shall provide interfaces that permit the application
to override the interfaces used for controlling mutexes.

SYSREQ S20200 S20000
The SQLite library shall provide interfaces that permit the application
to create new SQL functions.

  Most SQL database engines support a rich set of SQL functions.
  SQLite, in contrast, supports only a select few SQL functions.
  But SQLite makes up for its dearth of built-in SQL functions by 
  allowing the application to create new SQL function easily.

SYSREQ S20300 S20000
The SQLite library shall provide interfaces that permit the application
to create new text collating sequences.

  By default, SQLite only understands ASCII text.  The tables needed
  to do proper comparisons and case folding
  of full unicode text are huge - much larger
  than the SQLite library itself.  And, any application that is dealing
  with unicode already probably already has those tables built in.  For
  SQLite to include unicode comparison tables would be redundant and wasteful.
  As a compromise, SQLite allows the application to specify alternative
  collating sequences for things such as unicode text,
  so that for applications that need such comparison sequences can have
  them easily while other applications that are content with ASCII are
  not burdened with unnecessary tables.

SYSREQ S20400 S20000
The SQLite library shall provide interfaces that permit the application
to create new classes of virtual SQL tables.

  A virtual table is an SQL object that appears to be an ordinary
  SQL table for the purposes of INSERT, UPDATE, DELETE, and SELECT statements.
  But instead of being backed by persistent storage, the virtual table is
  an object that responds programmatically to INSERT, UPDATE, DELETE, and
  SELECT requests.  Virtual tables have been used to implement full-text
  search and R-Tree indices, among other things.

SYSREQ S20500 S20000
The SQLite library shall provide interfaces that permit the application
to load extensions at run-time using shared libraries.

  Some applications choose to package extensions in separate
  shared library files and load those extensions at run-time on
  an as-needed basis.  Depending on the nature of the application,
  this can be an aid to configuration management, since it allows
  the extension to be updated without having to replace the core
  application.

SYSREQ S20600 S20000
The SQLite library shall provide interfaces that permit the application
to dynamically query and modify size limits.

  SQLite has finite limits.  For example, there is a maximum size BLOB
  or CLOB that SQLite will store, a maximum size to a database file,
  a maximum number of columns in a table or query, and a maximum depth
  of an expression parse tree.  All of these have default values that
  are sufficiently large that a typical application is very unlikely to 
  ever reach the limits.  But some applications (for example, applications
  that process content from untrusted and possibly hostile sources)
  might want to define much lower limits on some database connections for
  the purpose of preventing denial-of-service attacks.  Or, an application
  might want to select much lower limits in order to prevent over-utilization
  of limited resources on an embedded device.  Whatever the rationale, SQLite
  permits limits to be queried and set at run-time.

SYSREQ S30000 
The SQLite library shall be safe for use in long-running,
low-resource, high-reliability applications.

  SQLite is designed to work well within embedded devices with 
  very limited resources.  To this end, it expects to confront situations
  where memory is unavailable and where I/O operations fail and it is designed
  to handle such situations with ease and grace.  SQLite also avoids aggravating
  low-resource situations by correctly freeing rather than leaking 
  resources it uses itself.

SYSREQ S30100 S30000
The SQLite library shall release all system resources it holds
when it is properly shutdown.

  A "Proper shutdown" means that all resources that the application
  has allocated from SQLite have been released by the application.
  The leak-free operation guarantee of SQLite applies even if there
  have been memory allocation errors or I/O errors during operation.

SYSREQ S30200 S30000
The SQLite library shall be configurable so that it is guaranteed
to never fail a memory allocation as long as the application does
not request resources in excess of reasonable and published limits.

  Safety-critical systems typically disallow the use of malloc() and
  free() because one never knows when they might fail due to memory
  fragmentation.  However, SQLite makes extensive use of dynamic objects
  and so it must be able to allocate and deallocate memory
  to hold those objects.</p>
  
  <p>In order to be acceptable for use in safety critical systems,
  SQLite can be configured to use its own internal memory allocator
  which, subject to proper usage by the application, guarantees that
  memory allocation will never fail either due to memory fragmentation
  or any other cause.  The proof of correctness is due to J. M. Robson:
  "Bounds for Some Functions Concerning Dynamic Storage Allocations",
  Journal of the ACM, Volume 21, Number 3, July 1974.</p>
  
  <p>The internal memory allocator is seeded with a large contiguous
  block of memory at application start.  SQLite makes all of its
  internal memory allocations from this initial seed.  
  The Robson proof depends on SQLite being coupled to a well-behaved
  application.  The application must not try to use more than a
  precomputed fraction of the available memory - that fraction depending
  on the size ratio between the largest and smallest memory allocations.
  Additional details are provided elsewhere.

SYSREQ S30210 S30200
The SQLite library shall be provide instrumentation that can alert
the application when its resource usages nears or exceeds the limits
of the memory breakdown guarantee.

  To help insure that an
  application never fails a memory allocation call, SQLite provides
  interfaces that can inform the application if its memory usage
  is growing close to or has exceeded the critical Robson limits.  
  In practice, the memory used by an application can exceed the 
  limits of the Robson proof by a wide margin with no harmful effect.  
  There is plenty of safety margin.  But the Robson proof does break 
  down once the limits are exceeded  
  and the guarantee that no memory allocation will fail is lost.  Hence
  it is important to be able to track how close an application has come
  to reaching critical limits.

SYSREQ S30220 S30200
The SQLite library shall be provide facilities to automatically
recycle memory when usage nears preset limits.

  When SQLite comes under memory pressure, it can be configured to
  recycle memory from one use to another, thus helping to reduce the
  pressure.  "Memory pressure" means that memory available for 
  allocation is becoming less plentiful.  In a safety-critical application,
  memory pressure might mean that the amount of allocated memory is
  getting close to the point where the Robson proof
  breaks down.  On a workstation, memory pressure might mean that
  available virtual memory is running low.

SYSREQ S30230 S30200
The SQLite library shall be permit BLOB and CLOB objects to be
read and written incrementally using small memory buffers.

  SQLite provides the ability to read and write megabyte
  or gigabyte blobs and text strings without having to allocate
  enough memory to hold the entire blob and string in memory all
  at once.  This enables SQLite to read and write BLOBs that
  are actually larger than the available memory on the device.
  It also helps reduce the size of the maximum memory allocation
  which helps keep memory usage below Robson limits and thus helps
  to guarantee failure-free memory allocation.

SYSREQ S30300 S30000
When a memory allocation fails, SQLite shall either silently make
due without the requested memory or else it shall report the error
back to the application.

  Memory allocation problems do not cause SQLite to fail
  catastrophically.
  SQLite recognizes all memory allocation failures and either works 
  around them, or
  cleanly aborts what it is doing and returns to the application
  with an error that indicates insufficient memory was available.
  Assuming new memory becomes available, SQLite is able to continue 
  operating normally after a memory allocation failure.

SYSREQ S30400 S30000
When a I/O operation fails, SQLite shall either silently
recover or else it shall report the error
back to the application.

  SQLite responses sanely to disk I/O errors.  If it is unable
  to work around the problem, SQLite might have to report the error
  back up to the application.  In either case, SQLite is able to
  continue functioning, assuming of course that the I/O error was
  transient.

SYSREQ S30500 S30000
SQLite shall provide the capability to monitor
the progress and interrupt the evaluation of a long-running query.

  SQLite is able to cleanly abort an operation in progress and
  afterwards continue functioning normally without any memory or
  other resource leaks.  An example of where this functionality is
  used occurs in the command-line interface (CLI) program for SQLite.
  If the user enters a query that has millions of result rows, those
  rows begin pouring out onto the screen.  The operator can then
  hit the interrupt key sequence (which varies from one operating
  system to another but it often Control-C) which causes the query
  to be aborted.

SYSREQ S30600 S30000
All unused portions of a well-formed SQLite database file shall
be available for reuse.

  When information is deleted from an SQLite database, the default
  action is for SQLite to mark the space as unused and then to reuse
  the space at the next opportune INSERT.  On devices where persistent 
  storage is scarce, however, it is sometime desirable to return the
  unused space back to the operating system.  SQLite supports this.

SYSREQ S30700 S30000
SQLite shall provide the capability to incrementally decrease the
size of the persistent storage file as information is removed from
the database.

SYSREQ S30800 S30000
SQLite shall provide the interfaces that support testing and
validation of the library code in an as-delivered configuration.

  In consumer-grade software, it is often acceptable to run tests
  on an instrumented version of the code.  But for high-reliability
  systems, it is better to test the code exactly as it is deployed.
  The saying at NASA is "test what you fly and fly what you test."
  In support of this goal, SQLite includes interfaces whose only purpose
  is to observe internal state and to place SQLite into internal states
  for the testing.

SYSREQ S30900 S30000
SQLite shall provide the ability for separate database connections
within the same process to share resources.

  On resource-constrained devices, it is desirable to get double-duty
  out of resources where possible.

SYSREQ S40000 
The SQLite library shall be safe for use in applications that
make concurrent access to the underlying database from different
threads and/or processes.

  In nearly all modern digital systems, there are many things happening
  at once.  And many of those things involve SQLite.

SYSREQ S40100 S40000
The SQLite library shall be configurable to operate correctly in
a multi-threaded application.

  The developers of SQLite believe that "thread-safe" is a
  self contradiction.  No application that includes multiple threads
  of control within the same address space is every truly "safe".
  And yet it is recognized that many developers want to
  create multithreaded applications and to use SQLite in those
  applications.  Therefore, SQLite is engineered to be "thread-safe".

SYSREQ S40200 S40000
The SQLite library shall support multiple independent database
connections per thread and per process.

SYSREQ S40300 S40000
The SQLite library shall automatically control access to common
databases from different connections in different threads or processes.

  SQLite uses both internal mutexes and external file locking to 
  ensure that two or more threads or processes working
  on the same database file play nicely with one another.

SYSREQ S40400 S40000
The SQLite library shall notify the application if an operation can
not be completed due to concurrent access constraints.

SYSREQ S40410 S40000
The SQLite library shall provide interfaces to assist the application
in responding appropriately when an operation can
not be completed due to concurrent access constraints.

  If an SQL statement cannot be completed because another process is
  holding a lock on the database, then the application needs to be able
  to take corrective action, such waiting for the lock to clear.


SYSREQ S50000 
The SQLite library shall be cross-platform.

  Cross-platform in this context means that the SQLite 
  can be used on a wide variety of operating systems and processors,
  ranging from small, special-purpose embedded systems, to workstations,
  to servers.  Platforms can be 32- or 64-bit, big-endian or little-endian.
  Cross-platform refers to the source code.  Obviously the SQLite would
  need to be recompiled in order to run on processors with different
  instruction sets.

SYSREQ S50100 S50000
The SQLite library shall be implemented in ANSI-C.

  C has been called the "universal assembly language".
  Nearly all computer systems accept code written in C.
  Thus, to help make SQLite cross-platform:

SYSREQ S50200 S50000
The SQLite library shall support text encoded as UTF-8,
UTF-16le, or UTF-16be.

SYSREQ S50300 S50000
SQLite database files shall be processor and byte-order independent.

  An SQLite database file can be freely moved between machine
  with different operating systems, different processors,
  different size integers, and different byte orders.  The same
  database file should work on any machine.

SYSREQ S60000 
The SQLite library shall provide introspection capabilities to the
application.

  Some applications need to be able to discover characteristics of
  their environment at run-time and to make appropriate adjustments to
  their processing to accommodate the environment they find themselves in.
  SQLite attempts to support this need.

SYSREQ S60100 S60000
The SQLite library shall provide interfaces that an application can
use to discover fixed, compile-time characteristics of the
SQLite library.

  Some applications are designed to work with different versions
  of SQLite which may or may not enable selected features.  For example,
  SQLite can be compiled to be threadsafe or not.  The threadsafe version
  works in multi-threaded applications.  The non-threadsafe build runs
  faster.  When an application is using an unknown version of SQLite
  it is important that it be able to determine the characteristics of
  the particular SQLite build it is using.

SYSREQ S60200 S60000
The SQLite library shall provide interfaces that an application can
use to find run-time performance characteristics and status of the
SQLite library.

SYSREQ S60300 S60000
The SQLite library shall provide interfaces that permit an application
to query the schema of a database.

SYSREQ S60400 S60000
The SQLite library shall provide interfaces that allow an application
to monitor sequence of queries and progress of submitted to SQLite.

SYSREQ S60500 S60000
The SQLite library shall provide interfaces that allow an application
to discover the algorithms that SQLite has chosen to implement specific
SQL statements.

SYSREQ S60600 S60000 S20200
The SQLite library shall provide interfaces that allow an application
to discover relationships between SQLite objects.

  SQLite objects are often related.  For example, every prepared
  statement is associated with a database connection.  And every
  function context is associated with a prepared statement.  
  Applications and extensions frequently find it useful to be able
  to discover these relationships at runtime.

SYSREQ S70000 
The SQLite library shall provide interfaces that promote the safe
construction and processing of SQL statements and data from
untrusted sources.

  Many applications need to be able to safely process data or
  even SQL statements that are received from untrusted sources.
  An "SQL Injection Attack" occurs when an adversary intentionally
  introduces data that is designed to have undesirable side effects
  on the database files.  For example, suppose an application generates
  an INSERT statement as follows:</p>
  
  <blockquote><pre>
  snprintf(z, n, "INSERT INTO table1 VALUES('%s')", zUserData);
  </pre></blockquote>
  
  <p>If a hostile user supplies data that reads:</p>
  
  <blockquote><pre>
  beginning'); DELETE FROM table1; INSERT INTO table1 VALUES('
  </pre></blockquote>
  
  <p>Then the constructed INSERT statement would be transformed into
  three statements, the second of which is an undesired deletion of
  all prior content from the table.  SQLite contains interfaces that
  are designed to help applications avoid SQL injection attacks and
  similar problems.

SYSREQ S70100 S70000
The SQLite library shall provide the application means by which the
application can test and enforce compliance with database access
policies for any particular SQL statement.

  Some applications (for example
  <a href="http://www.cvstrac.org/">CVSTrac</a> and
  <a href="http://www.fossil-scm.org/">Fossil</a>) will run SELECT
  statements entered by anonymous users on the internet.  Such 
  applications want to be able to guarantee that a hostile users does
  not access restricted tables (such as the PASSWORD column of the USER
  table) or modify the database in any way.  SQLite supports the ability
  to analyze an arbitrary SQL statement to insure that it does not
  perform undesired operations.

SYSREQ S70200 S70000
The SQLite library shall provide interfaces that test to see if an
SQL statement being received incrementally is complete.

  <p>Applications such as the command-line interface (CLI) for SQLite
  will prompt the user to enter SQL statements and will evaluate those
  statements as they are entered.  But sometimes an SQL statement spans
  multiple lines.  The CLI needs to know to issue a continuation prompt
  and await additional input if the input received so far is incomplete.
  SQLite supports interfaces that allow the CLI and similar applications
  to know if the input it has gathered so far is complete or if it needs
  to await additional input before processing the SQL.

SYSREQ S70300 S70000 S30000
The SQLite library shall support prepared statement objects with
late parameter binding

  The concept of a "prepared statement" allows an SQL statement to be
  parsed and compiled once and then reused many times.  This is a performance
  advantage in many applications.  In addition, binding values to variables
  in the prepared statement is safer than embedding values as literals because
  bound values do not need to be quoted in order to avoid an SQL injection
  attack.

SYSREQ S80000 
SQLite shall exhibit ductile failure characteristics

  A common characteristic of digital systems (as opposed to analog
  systems) is that digital systems tend to be brittle.  In other words,
  digital systems tend to work perfectly with no sign of stress until 
  they fail utterly and completely.  The behavior is like a
  physical object that holds its shape as external
  loads increase, until it shatters without warning.</p>
  
  <p>In most circumstances, ductile failure is preferred over brittle
  failure.  A ductile device begins showing signs of
  trouble well in advance of failure.  Physical objects bend and/or crack,
  providing operators with warnings of overload and an opportunity
  to take corrective action, while continuing to function for as long
  as possible.</p>
  
  <p>Digital systems have a reputation for being brittle, yet brittleness
  is not an intrinsic property of digital systems.  Digital systems can
  be designed to continuing functioning outside their design parameters
  while providing operators with warning of possible trouble.  But there
  most be focused effort on the part of the designers to make digital
  systems ductile.  With analog systems, the ductileness tends to be
  inherent in the medium, but with digital systems ductileness needs
  to be explicitly added.

SYSREQ S80100 S80000
SQLite shall make anomalies visible to the application

  SQLite strives to deal gracefully with anomalous behavior by
  the application or by its own internal subsystems.  Yet graceful
  handling of out-of-band inputs is of no value if the anomaly goes
  unreported.  The problems must be visible to the
  application so that warnings and alarms can be propagated to operators.
  The useful aspect of ductile failure is that it gives advance warning.
  Ductile behavior is of no use to anyone if nobody can see the part
  bending.

HLR H10010 S60100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_VERSION         "3.6.6"
#define SQLITE_VERSION_NUMBER  3006006
</pre></blockquote>

HLR H10011 S60100
The SQLITE_VERSION #define in the sqlite3.h header file shall
evaluate to a string literal that is the SQLite version
with which the header file is associated.

HLR H10014 S60100
The SQLITE_VERSION_NUMBER #define shall resolve to an integer
with the value (X*1000000 + Y*1000 + Z) where X, Y, and Z
are the major version, minor version, and release number.

HLR H10020 S60100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
SQLITE_EXTERN const char sqlite3_version[];
const char *sqlite3_libversion(void);
int sqlite3_libversion_number(void);
</pre></blockquote>

HLR H10021 S60100
The [sqlite3_libversion_number()] interface shall return
an integer equal to [SQLITE_VERSION_NUMBER].

HLR H10022 S60100
The [sqlite3_version] string constant shall contain
the text of the [SQLITE_VERSION] string.

HLR H10023 S60100
The [sqlite3_libversion()] function shall return
a pointer to the [sqlite3_version] string constant.

HLR H10100 S60100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_threadsafe(void);
</pre></blockquote>

HLR H10101 S60100
The [sqlite3_threadsafe()] function shall return zero if
and only if SQLite was compiled with mutexing code omitted.

HLR H10102 S60100
The value returned by the [sqlite3_threadsafe()] function
shall remain the same across calls to [sqlite3_config()].

HLR H10130 S20000 S30100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_initialize(void);
int sqlite3_shutdown(void);
int sqlite3_os_init(void);
int sqlite3_os_end(void);
</pre></blockquote>

HLR H10155 S20120
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_mem_methods sqlite3_mem_methods;
struct sqlite3_mem_methods {
void *(*xMalloc)(int);         /* Memory allocation function */
void (*xFree)(void*);          /* Free a prior allocation */
void *(*xRealloc)(void*,int);  /* Resize an allocation */
int (*xSize)(void*);           /* Return the size of an allocation */
int (*xRoundup)(int);          /* Round up request size to allocation size */
int (*xInit)(void*);           /* Initialize the memory allocator */
void (*xShutdown)(void*);      /* Deinitialize the memory allocator */
void *pAppData;                /* Argument to xInit() and xShutdown() */
};
</pre></blockquote>

HLR H10160 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_CONFIG_SINGLETHREAD  1  /* nil */
#define SQLITE_CONFIG_MULTITHREAD   2  /* nil */
#define SQLITE_CONFIG_SERIALIZED    3  /* nil */
#define SQLITE_CONFIG_MALLOC        4  /* sqlite3_mem_methods* */
#define SQLITE_CONFIG_GETMALLOC     5  /* sqlite3_mem_methods* */
#define SQLITE_CONFIG_SCRATCH       6  /* void*, int sz, int N */
#define SQLITE_CONFIG_PAGECACHE     7  /* void*, int sz, int N */
#define SQLITE_CONFIG_HEAP          8  /* void*, int nByte, int min */
#define SQLITE_CONFIG_MEMSTATUS     9  /* boolean */
#define SQLITE_CONFIG_MUTEX        10  /* sqlite3_mutex_methods* */
#define SQLITE_CONFIG_GETMUTEX     11  /* sqlite3_mutex_methods* */
/* previously SQLITE_CONFIG_CHUNKALLOC 12 which is now unused. */
#define SQLITE_CONFIG_LOOKASIDE    13  /* int int */
#define SQLITE_CONFIG_PCACHE       14  /* sqlite3_pcache_methods* */
#define SQLITE_CONFIG_GETPCACHE    15  /* sqlite3_pcache_methods* */
</pre></blockquote>

HLR H10170 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_DBCONFIG_LOOKASIDE    1001  /* void* int int */
</pre></blockquote>

HLR H10200 S10110
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#ifdef SQLITE_INT64_TYPE
typedef SQLITE_INT64_TYPE sqlite_int64;
typedef unsigned SQLITE_INT64_TYPE sqlite_uint64;
#elif defined(_MSC_VER) || defined(__BORLANDC__)
typedef __int64 sqlite_int64;
typedef unsigned __int64 sqlite_uint64;
#else
typedef long long int sqlite_int64;
typedef unsigned long long int sqlite_uint64;
#endif
typedef sqlite_int64 sqlite3_int64;
typedef sqlite_uint64 sqlite3_uint64;
</pre></blockquote>

HLR H10201 S10110
The [sqlite_int64] and [sqlite3_int64] type shall specify
a 64-bit signed integer.

HLR H10202 S10110
The [sqlite_uint64] and [sqlite3_uint64] type shall specify
a 64-bit unsigned integer.

HLR H10210 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_OK           0   /* Successful result */
/* beginning-of-error-codes */
#define SQLITE_ERROR        1   /* SQL error or missing database */
#define SQLITE_INTERNAL     2   /* Internal logic error in SQLite */
#define SQLITE_PERM         3   /* Access permission denied */
#define SQLITE_ABORT        4   /* Callback routine requested an abort */
#define SQLITE_BUSY         5   /* The database file is locked */
#define SQLITE_LOCKED       6   /* A table in the database is locked */
#define SQLITE_NOMEM        7   /* A malloc() failed */
#define SQLITE_READONLY     8   /* Attempt to write a readonly database */
#define SQLITE_INTERRUPT    9   /* Operation terminated by sqlite3_interrupt()*/
#define SQLITE_IOERR       10   /* Some kind of disk I/O error occurred */
#define SQLITE_CORRUPT     11   /* The database disk image is malformed */
#define SQLITE_NOTFOUND    12   /* NOT USED. Table or record not found */
#define SQLITE_FULL        13   /* Insertion failed because database is full */
#define SQLITE_CANTOPEN    14   /* Unable to open the database file */
#define SQLITE_PROTOCOL    15   /* NOT USED. Database lock protocol error */
#define SQLITE_EMPTY       16   /* Database is empty */
#define SQLITE_SCHEMA      17   /* The database schema changed */
#define SQLITE_TOOBIG      18   /* String or BLOB exceeds size limit */
#define SQLITE_CONSTRAINT  19   /* Abort due to constraint violation */
#define SQLITE_MISMATCH    20   /* Data type mismatch */
#define SQLITE_MISUSE      21   /* Library used incorrectly */
#define SQLITE_NOLFS       22   /* Uses OS features not supported on host */
#define SQLITE_AUTH        23   /* Authorization denied */
#define SQLITE_FORMAT      24   /* Auxiliary database format error */
#define SQLITE_RANGE       25   /* 2nd parameter to sqlite3_bind out of range */
#define SQLITE_NOTADB      26   /* File opened that is not a database file */
#define SQLITE_ROW         100  /* sqlite3_step() has another row ready */
#define SQLITE_DONE        101  /* sqlite3_step() has finished executing */
/* end-of-error-codes */
</pre></blockquote>

HLR H10220 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_IOERR_READ              (SQLITE_IOERR | (1&lt;&lt;8))
#define SQLITE_IOERR_SHORT_READ        (SQLITE_IOERR | (2&lt;&lt;8))
#define SQLITE_IOERR_WRITE             (SQLITE_IOERR | (3&lt;&lt;8))
#define SQLITE_IOERR_FSYNC             (SQLITE_IOERR | (4&lt;&lt;8))
#define SQLITE_IOERR_DIR_FSYNC         (SQLITE_IOERR | (5&lt;&lt;8))
#define SQLITE_IOERR_TRUNCATE          (SQLITE_IOERR | (6&lt;&lt;8))
#define SQLITE_IOERR_FSTAT             (SQLITE_IOERR | (7&lt;&lt;8))
#define SQLITE_IOERR_UNLOCK            (SQLITE_IOERR | (8&lt;&lt;8))
#define SQLITE_IOERR_RDLOCK            (SQLITE_IOERR | (9&lt;&lt;8))
#define SQLITE_IOERR_DELETE            (SQLITE_IOERR | (10&lt;&lt;8))
#define SQLITE_IOERR_BLOCKED           (SQLITE_IOERR | (11&lt;&lt;8))
#define SQLITE_IOERR_NOMEM             (SQLITE_IOERR | (12&lt;&lt;8))
#define SQLITE_IOERR_ACCESS            (SQLITE_IOERR | (13&lt;&lt;8))
#define SQLITE_IOERR_CHECKRESERVEDLOCK (SQLITE_IOERR | (14&lt;&lt;8))
#define SQLITE_IOERR_LOCK              (SQLITE_IOERR | (15&lt;&lt;8))
#define SQLITE_IOERR_CLOSE             (SQLITE_IOERR | (16&lt;&lt;8))
#define SQLITE_IOERR_DIR_CLOSE         (SQLITE_IOERR | (17&lt;&lt;8))
</pre></blockquote>

HLR H10223 S10700
The symbolic name for an extended result code shall contains
a related primary result code as a prefix.

HLR H10224 S10700
Primary result code names shall contain a single "_" character.

HLR H10225 S10700
Extended result code names shall contain two or more "_" characters.

HLR H10226 S10700
The numeric value of an extended result code shall contain the
numeric value of its corresponding primary result code in
its least significant 8 bits.

HLR H10230 H11120 H12700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_OPEN_READONLY         0x00000001
#define SQLITE_OPEN_READWRITE        0x00000002
#define SQLITE_OPEN_CREATE           0x00000004
#define SQLITE_OPEN_DELETEONCLOSE    0x00000008
#define SQLITE_OPEN_EXCLUSIVE        0x00000010
#define SQLITE_OPEN_MAIN_DB          0x00000100
#define SQLITE_OPEN_TEMP_DB          0x00000200
#define SQLITE_OPEN_TRANSIENT_DB     0x00000400
#define SQLITE_OPEN_MAIN_JOURNAL     0x00000800
#define SQLITE_OPEN_TEMP_JOURNAL     0x00001000
#define SQLITE_OPEN_SUBJOURNAL       0x00002000
#define SQLITE_OPEN_MASTER_JOURNAL   0x00004000
#define SQLITE_OPEN_NOMUTEX          0x00008000
#define SQLITE_OPEN_FULLMUTEX        0x00010000
</pre></blockquote>

HLR H10240 H11120
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_IOCAP_ATOMIC          0x00000001
#define SQLITE_IOCAP_ATOMIC512       0x00000002
#define SQLITE_IOCAP_ATOMIC1K        0x00000004
#define SQLITE_IOCAP_ATOMIC2K        0x00000008
#define SQLITE_IOCAP_ATOMIC4K        0x00000010
#define SQLITE_IOCAP_ATOMIC8K        0x00000020
#define SQLITE_IOCAP_ATOMIC16K       0x00000040
#define SQLITE_IOCAP_ATOMIC32K       0x00000080
#define SQLITE_IOCAP_ATOMIC64K       0x00000100
#define SQLITE_IOCAP_SAFE_APPEND     0x00000200
#define SQLITE_IOCAP_SEQUENTIAL      0x00000400
</pre></blockquote>

HLR H10250 H11120 H11310
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_LOCK_NONE          0
#define SQLITE_LOCK_SHARED        1
#define SQLITE_LOCK_RESERVED      2
#define SQLITE_LOCK_PENDING       3
#define SQLITE_LOCK_EXCLUSIVE     4
</pre></blockquote>

HLR H10260 H11120
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_SYNC_NORMAL        0x00002
#define SQLITE_SYNC_FULL          0x00003
#define SQLITE_SYNC_DATAONLY      0x00010
</pre></blockquote>

HLR H10265 S10110 S10120
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_INTEGER  1
#define SQLITE_FLOAT    2
#define SQLITE_BLOB     4
#define SQLITE_NULL     5
#ifdef SQLITE_TEXT
# undef SQLITE_TEXT
#else
# define SQLITE_TEXT     3
#endif
#define SQLITE3_TEXT     3
</pre></blockquote>

HLR H10267 S50200 H16100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_UTF8           1
#define SQLITE_UTF16LE        2
#define SQLITE_UTF16BE        3
#define SQLITE_UTF16          4    /* Use native byte order */
#define SQLITE_ANY            5    /* sqlite3_create_function only */
#define SQLITE_UTF16_ALIGNED  8    /* sqlite3_create_collation only */
</pre></blockquote>

HLR H10280 S30100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef void (*sqlite3_destructor_type)(void*);
#define SQLITE_STATIC      ((sqlite3_destructor_type)0)
#define SQLITE_TRANSIENT   ((sqlite3_destructor_type)-1)
</pre></blockquote>

HLR H10310 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
SQLITE_EXTERN char *sqlite3_temp_directory;
</pre></blockquote>

HLR H10330 S30900
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_enable_shared_cache(int);
</pre></blockquote>

HLR H10331 S30900
A successful invocation of [sqlite3_enable_shared_cache(B)]
will enable or disable shared cache mode for any subsequently
created [database connection] in the same process.

HLR H10336 S30900
When shared cache is enabled, the [sqlite3_create_module()]
interface will always return an error.

HLR H10337 S30900
The [sqlite3_enable_shared_cache(B)] interface returns
[SQLITE_OK] if shared cache was enabled or disabled successfully.

HLR H10339 S30900
Shared cache is disabled by default.

HLR H10510 S70200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_complete(const char *sql);
int sqlite3_complete16(const void *sql);
</pre></blockquote>

HLR H10511 S70200
A successful evaluation of [sqlite3_complete()] or
[sqlite3_complete16()] functions shall
return a numeric 1 if and only if the last non-whitespace
token in their input is a semicolon that is not in between
the BEGIN and END of a CREATE TRIGGER statement.

HLR H10512 S70200
If a memory allocation error occurs during an invocation
of [sqlite3_complete()] or [sqlite3_complete16()] then the
routine shall return [SQLITE_NOMEM].

HLR H10530 S40410
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_sleep(int);
</pre></blockquote>

HLR H10533 S40410
The [sqlite3_sleep(M)] interface invokes the xSleep
method of the default [sqlite3_vfs|VFS] in order to
suspend execution of the current thread for at least
M milliseconds.

HLR H10536 S40410
The [sqlite3_sleep(M)] interface returns the number of
milliseconds of sleep actually requested of the operating
system, which might be larger than the parameter M.

HLR H11110 S20110
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_file sqlite3_file;
struct sqlite3_file {
const struct sqlite3_io_methods *pMethods;  /* Methods for an open file */
};
</pre></blockquote>

HLR H11120 S20110
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_io_methods sqlite3_io_methods;
struct sqlite3_io_methods {
int iVersion;
int (*xClose)(sqlite3_file*);
int (*xRead)(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst);
int (*xWrite)(sqlite3_file*, const void*, int iAmt, sqlite3_int64 iOfst);
int (*xTruncate)(sqlite3_file*, sqlite3_int64 size);
int (*xSync)(sqlite3_file*, int flags);
int (*xFileSize)(sqlite3_file*, sqlite3_int64 *pSize);
int (*xLock)(sqlite3_file*, int);
int (*xUnlock)(sqlite3_file*, int);
int (*xCheckReservedLock)(sqlite3_file*, int *pResOut);
int (*xFileControl)(sqlite3_file*, int op, void *pArg);
int (*xSectorSize)(sqlite3_file*);
int (*xDeviceCharacteristics)(sqlite3_file*);
/* Additional methods may be added in future releases */
};
</pre></blockquote>

HLR H11140 S20100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_vfs sqlite3_vfs;
struct sqlite3_vfs {
int iVersion;            /* Structure version number */
int szOsFile;            /* Size of subclassed sqlite3_file */
int mxPathname;          /* Maximum file pathname length */
sqlite3_vfs *pNext;      /* Next registered VFS */
const char *zName;       /* Name of this virtual file system */
void *pAppData;          /* Pointer to application-specific data */
int (*xOpen)(sqlite3_vfs*, const char *zName, sqlite3_file*,
int flags, int *pOutFlags);
int (*xDelete)(sqlite3_vfs*, const char *zName, int syncDir);
int (*xAccess)(sqlite3_vfs*, const char *zName, int flags, int *pResOut);
int (*xFullPathname)(sqlite3_vfs*, const char *zName, int nOut, char *zOut);
void *(*xDlOpen)(sqlite3_vfs*, const char *zFilename);
void (*xDlError)(sqlite3_vfs*, int nByte, char *zErrMsg);
void (*(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol))(void);
void (*xDlClose)(sqlite3_vfs*, void*);
int (*xRandomness)(sqlite3_vfs*, int nByte, char *zOut);
int (*xSleep)(sqlite3_vfs*, int microseconds);
int (*xCurrentTime)(sqlite3_vfs*, double*);
int (*xGetLastError)(sqlite3_vfs*, int, char *);
/* New fields may be appended in figure versions.  The iVersion
** value will increment whenever this happens. */
};
</pre></blockquote>

HLR H11190 H11140
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_ACCESS_EXISTS    0
#define SQLITE_ACCESS_READWRITE 1
#define SQLITE_ACCESS_READ      2
</pre></blockquote>

HLR H11200 S20100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);
int sqlite3_vfs_register(sqlite3_vfs*, int makeDflt);
int sqlite3_vfs_unregister(sqlite3_vfs*);
</pre></blockquote>

HLR H11203 S20100
The [sqlite3_vfs_find(N)] interface returns a pointer to the
registered [sqlite3_vfs] object whose name exactly matches
the zero-terminated UTF-8 string N, or it returns NULL if
there is no match.

HLR H11206 S20100
If the N parameter to [sqlite3_vfs_find(N)] is NULL then
the function returns a pointer to the default [sqlite3_vfs]
object if there is one, or NULL if there is no default
[sqlite3_vfs] object.

HLR H11209 S20100
The [sqlite3_vfs_register(P,F)] interface registers the
well-formed [sqlite3_vfs] object P using the name given
by the zName field of the object.

HLR H11212 S20100
Using the [sqlite3_vfs_register(P,F)] interface to register
the same [sqlite3_vfs] object multiple times is a harmless no-op.

HLR H11215 S20100
The [sqlite3_vfs_register(P,F)] interface makes the [sqlite3_vfs]
object P the default [sqlite3_vfs] object if F is non-zero.

HLR H11218 S20100
The [sqlite3_vfs_unregister(P)] interface unregisters the
[sqlite3_vfs] object P so that it is no longer returned by
subsequent calls to [sqlite3_vfs_find()].

HLR H11300 S30800
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_file_control(sqlite3*, const char *zDbName, int op, void*);
</pre></blockquote>

HLR H11302 S70300
The [sqlite3_finalize(S)] interface destroys the
[prepared statement] S and releases all
memory and file resources held by that object.

HLR H11304 S70300
If the most recent call to [sqlite3_step(S)] for the
[prepared statement] S returned an error,
then [sqlite3_finalize(S)] returns that same error.

HLR H11310 S30800
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_FCNTL_LOCKSTATE        1
#define SQLITE_GET_LOCKPROXYFILE      2
#define SQLITE_SET_LOCKPROXYFILE      3
#define SQLITE_LAST_ERRNO             4
</pre></blockquote>

HLR H11400 S30800
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_test_control(int op, ...);
</pre></blockquote>

HLR H11410 H11400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_TESTCTRL_PRNG_SAVE                5
#define SQLITE_TESTCTRL_PRNG_RESTORE             6
#define SQLITE_TESTCTRL_PRNG_RESET               7
#define SQLITE_TESTCTRL_BITVEC_TEST              8
#define SQLITE_TESTCTRL_FAULT_INSTALL            9
#define SQLITE_TESTCTRL_BENIGN_MALLOC_HOOKS     10
</pre></blockquote>

HLR H12000 S40200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3 sqlite3;
</pre></blockquote>

HLR H12010 S30100 S40200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_close(sqlite3 *);
</pre></blockquote>

HLR H12011 S30100
A successful call to [sqlite3_close(C)] shall destroy the
[database connection] object C.

HLR H12012 S30100
A successful call to [sqlite3_close(C)] shall return SQLITE_OK.

HLR H12013 S30100
A successful call to [sqlite3_close(C)] shall release all
memory and system resources associated with [database connection]
C.

HLR H12014 S30100
A call to [sqlite3_close(C)] on a [database connection] C that
has one or more open [prepared statements] shall fail with
an [SQLITE_BUSY] error code.

HLR H12015 S30100
A call to [sqlite3_close(C)] where C is a NULL pointer shall
be a harmless no-op returning SQLITE_OK.

HLR H12019 S30100
When [sqlite3_close(C)] is invoked on a [database connection] C
that has a pending transaction, the transaction shall be
rolled back.

HLR H12100 S10000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_exec(
sqlite3*,                                  /* An open database */
const char *sql,                           /* SQL to be evaluated */
int (*callback)(void*,int,char**,char**),  /* Callback function */
void *,                                    /* 1st argument to callback */
char **errmsg                              /* Error msg written here */
);
</pre></blockquote>

HLR H12101 S10000
A successful invocation of [sqlite3_exec(D,S,C,A,E)]
shall sequentially evaluate all of the UTF-8 encoded,
semicolon-separated SQL statements in the zero-terminated
string S within the context of the [database connection] D.

HLR H12102 S10000
If the S parameter to [sqlite3_exec(D,S,C,A,E)] is NULL then
the actions of the interface shall be the same as if the
S parameter were an empty string.

HLR H12104 S10000
The return value of [sqlite3_exec()] shall be [SQLITE_OK] if all
SQL statements run successfully and to completion.

HLR H12105 S10000
The return value of [sqlite3_exec()] shall be an appropriate
non-zero [error code] if any SQL statement fails.

HLR H12107 S10000
If one or more of the SQL statements handed to [sqlite3_exec()]
return results and the 3rd parameter is not NULL, then
the callback function specified by the 3rd parameter shall be
invoked once for each row of result.

HLR H12110 S10000
If the callback returns a non-zero value then [sqlite3_exec()]
shall abort the SQL statement it is currently evaluating,
skip all subsequent SQL statements, and return [SQLITE_ABORT].

HLR H12113 S10000
The [sqlite3_exec()] routine shall pass its 4th parameter through
as the 1st parameter of the callback.

HLR H12116 S10000
The [sqlite3_exec()] routine shall set the 2nd parameter of its
callback to be the number of columns in the current row of
result.

HLR H12119 S10000
The [sqlite3_exec()] routine shall set the 3rd parameter of its
callback to be an array of pointers to strings holding the
values for each column in the current result set row as
obtained from [sqlite3_column_text()].

HLR H12122 S10000
The [sqlite3_exec()] routine shall set the 4th parameter of its
callback to be an array of pointers to strings holding the
names of result columns as obtained from [sqlite3_column_name()].

HLR H12125 S10000
If the 3rd parameter to [sqlite3_exec()] is NULL then
[sqlite3_exec()] shall silently discard query results.

HLR H12131 S10000
If an error occurs while parsing or evaluating any of the SQL
statements in the S parameter of [sqlite3_exec(D,S,C,A,E)] and if
the E parameter is not NULL, then [sqlite3_exec()] shall store
in *E an appropriate error message written into memory obtained
from [sqlite3_malloc()].

HLR H12134 S10000
The [sqlite3_exec(D,S,C,A,E)] routine shall set the value of
*E to NULL if E is not NULL and there are no errors.

HLR H12137 S10000
The [sqlite3_exec(D,S,C,A,E)] function shall set the [error code]
and message accessible via [sqlite3_errcode()],
[sqlite3_extended_errcode()],
[sqlite3_errmsg()], and [sqlite3_errmsg16()].

HLR H12138 S10000
If the S parameter to [sqlite3_exec(D,S,C,A,E)] is NULL or an
empty string or contains nothing other than whitespace, comments,
and/or semicolons, then results of [sqlite3_errcode()],
[sqlite3_extended_errcode()],
[sqlite3_errmsg()], and [sqlite3_errmsg16()]
shall reset to indicate no errors.

HLR H12200 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_extended_result_codes(sqlite3*, int onoff);
</pre></blockquote>

HLR H12201 S10700
Each new [database connection] shall have the
[extended result codes] feature disabled by default.

HLR H12202 S10700
The [sqlite3_extended_result_codes(D,F)] interface shall enable
[extended result codes] for the  [database connection] D
if the F parameter is true, or disable them if F is false.

HLR H12220 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*);
</pre></blockquote>

HLR H12221 S10700
The [sqlite3_last_insert_rowid()] function shall return the rowid
of the most recent successful [INSERT] performed on the same
[database connection] and within the same or higher level
trigger context, or zero if there have been no qualifying
[INSERT] statements.

HLR H12223 S10700
The [sqlite3_last_insert_rowid()] function shall return the
same value when called from the same trigger context
immediately before and after a [ROLLBACK].

HLR H12240 S10600
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_changes(sqlite3*);
</pre></blockquote>

HLR H12241 S10600
The [sqlite3_changes()] function shall return the number of
row changes caused by the most recent INSERT, UPDATE,
or DELETE statement on the same database connection and
within the same or higher trigger context, or zero if there have
not been any qualifying row changes.

HLR H12243 S10600
Statements of the form "DELETE FROM tablename" with no
WHERE clause shall cause subsequent calls to
[sqlite3_changes()] to return zero, regardless of the
number of rows originally in the table.

HLR H12260 S10600
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_total_changes(sqlite3*);
</pre></blockquote>

HLR H12261 S10600
The [sqlite3_total_changes()] returns the total number
of row changes caused by INSERT, UPDATE, and/or DELETE
statements on the same [database connection], in any
trigger context, since the database connection was created.

HLR H12263 S10600
Statements of the form "DELETE FROM tablename" with no
WHERE clause shall not change the value returned
by [sqlite3_total_changes()].

HLR H12270 S30500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void sqlite3_interrupt(sqlite3*);
</pre></blockquote>

HLR H12271 S30500
The [sqlite3_interrupt()] interface will force all running
SQL statements associated with the same database connection
to halt after processing at most one additional row of data.

HLR H12272 S30500
Any SQL statement that is interrupted by [sqlite3_interrupt()]
will return [SQLITE_INTERRUPT].

HLR H12280 S60400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_trace(sqlite3*, void(*xTrace)(void*,const char*), void*);
void *sqlite3_profile(sqlite3*,
void(*xProfile)(void*,const char*,sqlite3_uint64), void*);
</pre></blockquote>

HLR H12281 S60400
The callback function registered by [sqlite3_trace()]
shall be invoked
whenever an SQL statement first begins to execute and
whenever a trigger subprogram first begins to run.

HLR H12282 S60400
Each call to [sqlite3_trace()] shall override the previously
registered trace callback.

HLR H12283 S60400
A NULL trace callback shall disable tracing.

HLR H12284 S60400
The first argument to the trace callback shall be a copy of
the pointer which was the 3rd argument to [sqlite3_trace()].

HLR H12285 S60400
The second argument to the trace callback is a
zero-terminated UTF-8 string containing the original text
of the SQL statement as it was passed into [sqlite3_prepare_v2()]
or the equivalent, or an SQL comment indicating the beginning
of a trigger subprogram.

HLR H12287 S60400
The callback function registered by [sqlite3_profile()] is invoked
as each SQL statement finishes.

HLR H12288 S60400
The first parameter to the profile callback is a copy of
the 3rd parameter to [sqlite3_profile()].

HLR H12289 S60400
The second parameter to the profile callback is a
zero-terminated UTF-8 string that contains the complete text of
the SQL statement as it was processed by [sqlite3_prepare_v2()]
or the equivalent.

HLR H12290 S60400
The third parameter to the profile callback is an estimate
of the number of nanoseconds of wall-clock time required to
run the SQL statement from start to finish.

HLR H12310 S40400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*);
</pre></blockquote>

HLR H12311 S40400
The [sqlite3_busy_handler(D,C,A)] function shall replace
busy callback in the [database connection] D with a new
a new busy handler C and application data pointer A.

HLR H12312 S40400
Newly created [database connections] shall have a busy
handler of NULL.

HLR H12314 S40400
When two or more [database connections] share a
[sqlite3_enable_shared_cache | common cache],
the busy handler for the database connection currently using
the cache shall be invoked when the cache encounters a lock.

HLR H12316 S40400
If a busy handler callback returns zero, then the SQLite interface
that provoked the locking event shall return [SQLITE_BUSY].

HLR H12318 S40400
SQLite shall invokes the busy handler with two arguments which
are a copy of the pointer supplied by the 3rd parameter to
[sqlite3_busy_handler()] and a count of the number of prior
invocations of the busy handler for the same locking event.

HLR H12340 S40410
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_busy_timeout(sqlite3*, int ms);
</pre></blockquote>

HLR H12341 S40410
The [sqlite3_busy_timeout()] function shall override any prior
[sqlite3_busy_timeout()] or [sqlite3_busy_handler()] setting
on the same [database connection].

HLR H12343 S40410
If the 2nd parameter to [sqlite3_busy_timeout()] is less than
or equal to zero, then the busy handler shall be cleared so that
all subsequent locking events immediately return [SQLITE_BUSY].

HLR H12344 S40410
If the 2nd parameter to [sqlite3_busy_timeout()] is a positive
number N, then a busy handler shall be set that repeatedly calls
the xSleep() method in the [sqlite3_vfs | VFS interface] until
either the lock clears or until the cumulative sleep time
reported back by xSleep() exceeds N milliseconds.

HLR H12370 S10000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_get_table(
sqlite3 *db,          /* An open database */
const char *zSql,     /* SQL to be evaluated */
char ***pazResult,    /* Results of the query */
int *pnRow,           /* Number of result rows written here */
int *pnColumn,        /* Number of result columns written here */
char **pzErrmsg       /* Error msg written here */
);
void sqlite3_free_table(char **result);
</pre></blockquote>

HLR H12371 S10000
If a [sqlite3_get_table()] fails a memory allocation, then
it shall free the result table under construction, abort the
query in process, skip any subsequent queries, set the
*pazResult output pointer to NULL and return [SQLITE_NOMEM].

HLR H12373 S10000
If the pnColumn parameter to [sqlite3_get_table()] is not NULL
then a successful invocation of [sqlite3_get_table()] shall
write the number of columns in the
result set of the query into *pnColumn.

HLR H12374 S10000
If the pnRow parameter to [sqlite3_get_table()] is not NULL
then a successful invocation of [sqlite3_get_table()] shall
writes the number of rows in the
result set of the query into *pnRow.

HLR H12376 S10000
A successful invocation of [sqlite3_get_table()] that computes
N rows of result with C columns per row shall make *pazResult
point to an array of pointers to (N+1)*C strings where the first
C strings are column names as obtained from
[sqlite3_column_name()] and the rest are column result values
obtained from [sqlite3_column_text()].

HLR H12379 S10000
The values in the pazResult array returned by [sqlite3_get_table()]
shall remain valid until cleared by [sqlite3_free_table()].

HLR H12382 S10000
When an error occurs during evaluation of [sqlite3_get_table()]
the function shall set *pazResult to NULL, write an error message
into memory obtained from [sqlite3_malloc()], make
**pzErrmsg point to that error message, and return a
appropriate [error code].

HLR H12500 S70100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_set_authorizer(
sqlite3*,
int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
void *pUserData
);
</pre></blockquote>

HLR H12501 S70100
The [sqlite3_set_authorizer(D,...)] interface registers a
authorizer callback with database connection D.

HLR H12502 S70100
The authorizer callback is invoked as SQL statements are
being parseed and compiled.

HLR H12503 S70100
If the authorizer callback returns any value other than
[SQLITE_IGNORE], [SQLITE_OK], or [SQLITE_DENY], then
the application interface call that caused
the authorizer callback to run shall fail with an
[SQLITE_ERROR] error code and an appropriate error message.

HLR H12504 S70100
When the authorizer callback returns [SQLITE_OK], the operation
described is processed normally.

HLR H12505 S70100
When the authorizer callback returns [SQLITE_DENY], the
application interface call that caused the
authorizer callback to run shall fail
with an [SQLITE_ERROR] error code and an error message
explaining that access is denied.

HLR H12506 S70100
If the authorizer code (the 2nd parameter to the authorizer
callback) is [SQLITE_READ] and the authorizer callback returns
[SQLITE_IGNORE], then the prepared statement is constructed to
insert a NULL value in place of the table column that would have
been read if [SQLITE_OK] had been returned.

HLR H12507 S70100
If the authorizer code (the 2nd parameter to the authorizer
callback) is anything other than [SQLITE_READ], then
a return of [SQLITE_IGNORE] has the same effect as [SQLITE_DENY].

HLR H12510 S70100
The first parameter to the authorizer callback is a copy of
the third parameter to the [sqlite3_set_authorizer()] interface.

HLR H12511 S70100
The second parameter to the callback is an integer
[SQLITE_COPY | action code] that specifies the particular action
to be authorized.

HLR H12512 S70100
The third through sixth parameters to the callback are
zero-terminated strings that contain
additional details about the action to be authorized.

HLR H12520 S70100
Each call to [sqlite3_set_authorizer()] overrides
any previously installed authorizer.

HLR H12521 S70100
A NULL authorizer means that no authorization
callback is invoked.

HLR H12522 S70100
The default authorizer is NULL.

HLR H12550 H12500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
/******************************************* 3rd ************ 4th ***********/
#define SQLITE_CREATE_INDEX          1   /* Index Name      Table Name      */
#define SQLITE_CREATE_TABLE          2   /* Table Name      NULL            */
#define SQLITE_CREATE_TEMP_INDEX     3   /* Index Name      Table Name      */
#define SQLITE_CREATE_TEMP_TABLE     4   /* Table Name      NULL            */
#define SQLITE_CREATE_TEMP_TRIGGER   5   /* Trigger Name    Table Name      */
#define SQLITE_CREATE_TEMP_VIEW      6   /* View Name       NULL            */
#define SQLITE_CREATE_TRIGGER        7   /* Trigger Name    Table Name      */
#define SQLITE_CREATE_VIEW           8   /* View Name       NULL            */
#define SQLITE_DELETE                9   /* Table Name      NULL            */
#define SQLITE_DROP_INDEX           10   /* Index Name      Table Name      */
#define SQLITE_DROP_TABLE           11   /* Table Name      NULL            */
#define SQLITE_DROP_TEMP_INDEX      12   /* Index Name      Table Name      */
#define SQLITE_DROP_TEMP_TABLE      13   /* Table Name      NULL            */
#define SQLITE_DROP_TEMP_TRIGGER    14   /* Trigger Name    Table Name      */
#define SQLITE_DROP_TEMP_VIEW       15   /* View Name       NULL            */
#define SQLITE_DROP_TRIGGER         16   /* Trigger Name    Table Name      */
#define SQLITE_DROP_VIEW            17   /* View Name       NULL            */
#define SQLITE_INSERT               18   /* Table Name      NULL            */
#define SQLITE_PRAGMA               19   /* Pragma Name     1st arg or NULL */
#define SQLITE_READ                 20   /* Table Name      Column Name     */
#define SQLITE_SELECT               21   /* NULL            NULL            */
#define SQLITE_TRANSACTION          22   /* NULL            NULL            */
#define SQLITE_UPDATE               23   /* Table Name      Column Name     */
#define SQLITE_ATTACH               24   /* Filename        NULL            */
#define SQLITE_DETACH               25   /* Database Name   NULL            */
#define SQLITE_ALTER_TABLE          26   /* Database Name   Table Name      */
#define SQLITE_REINDEX              27   /* Index Name      NULL            */
#define SQLITE_ANALYZE              28   /* Table Name      NULL            */
#define SQLITE_CREATE_VTABLE        29   /* Table Name      Module Name     */
#define SQLITE_DROP_VTABLE          30   /* Table Name      Module Name     */
#define SQLITE_FUNCTION             31   /* NULL            Function Name   */
#define SQLITE_COPY                  0   /* No longer used */
</pre></blockquote>

HLR H12551 H12500
The second parameter to an
[sqlite3_set_authorizer | authorizer callback] shall be an integer
[SQLITE_COPY | authorizer code] that specifies what action
is being authorized.

HLR H12552 H12500
The 3rd and 4th parameters to the
[sqlite3_set_authorizer | authorization callback]
shall be parameters or NULL depending on which
[SQLITE_COPY | authorizer code] is used as the second parameter.

HLR H12553 H12500
The 5th parameter to the
[sqlite3_set_authorizer | authorizer callback] shall be the name
of the database (example: "main", "temp", etc.) if applicable.

HLR H12554 H12500
The 6th parameter to the
[sqlite3_set_authorizer | authorizer callback] shall be the name
of the inner-most trigger or view that is responsible for
the access attempt or NULL if this access attempt is directly from
top-level SQL code.

HLR H12590 H12500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_DENY   1   /* Abort the SQL statement with an error */
#define SQLITE_IGNORE 2   /* Don't allow access, but don't generate an error */
</pre></blockquote>

HLR H12600 S20500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_load_extension(
sqlite3 *db,          /* Load the extension into this database connection */
const char *zFile,    /* Name of the shared library containing extension */
const char *zProc,    /* Entry point.  Derived from zFile if 0 */
char **pzErrMsg       /* Put error message here if not 0 */
);
</pre></blockquote>

HLR H12620 S20500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_enable_load_extension(sqlite3 *db, int onoff);
</pre></blockquote>

HLR H12640 S20500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_auto_extension(void (*xEntryPoint)(void));
</pre></blockquote>

HLR H12660 S20500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void sqlite3_reset_auto_extension(void);
</pre></blockquote>

HLR H12700 S40200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_open(
const char *filename,   /* Database filename (UTF-8) */
sqlite3 **ppDb          /* OUT: SQLite db handle */
);
int sqlite3_open16(
const void *filename,   /* Database filename (UTF-16) */
sqlite3 **ppDb          /* OUT: SQLite db handle */
);
int sqlite3_open_v2(
const char *filename,   /* Database filename (UTF-8) */
sqlite3 **ppDb,         /* OUT: SQLite db handle */
int flags,              /* Flags */
const char *zVfs        /* Name of VFS module to use */
);
</pre></blockquote>

HLR H12701 S40200
The [sqlite3_open()], [sqlite3_open16()], and
[sqlite3_open_v2()] interfaces create a new
[database connection] associated with
the database file given in their first parameter.

HLR H12702 S40200
The filename argument is interpreted as UTF-8
for [sqlite3_open()] and [sqlite3_open_v2()] and as UTF-16
in the native byte order for [sqlite3_open16()].

HLR H12703 S40200
A successful invocation of [sqlite3_open()], [sqlite3_open16()],
or [sqlite3_open_v2()] writes a pointer to a new
[database connection] into *ppDb.

HLR H12704 S40200
The [sqlite3_open()], [sqlite3_open16()], and
[sqlite3_open_v2()] interfaces return [SQLITE_OK] upon success,
or an appropriate [error code] on failure.

HLR H12706 S40200
The default text encoding for a new database created using
[sqlite3_open()] or [sqlite3_open_v2()] will be UTF-8.

HLR H12707 S40200
The default text encoding for a new database created using
[sqlite3_open16()] will be UTF-16.

HLR H12709 S40200
The [sqlite3_open(F,D)] interface is equivalent to
[sqlite3_open_v2(F,D,G,0)] where the G parameter is
[SQLITE_OPEN_READWRITE]|[SQLITE_OPEN_CREATE].

HLR H12711 S40200
If the G parameter to [sqlite3_open_v2(F,D,G,V)] contains the
bit value [SQLITE_OPEN_READONLY] then the database is opened
for reading only.

HLR H12712 S40200
If the G parameter to [sqlite3_open_v2(F,D,G,V)] contains the
bit value [SQLITE_OPEN_READWRITE] then the database is opened
reading and writing if possible, or for reading only if the
file is write protected by the operating system.

HLR H12713 S40200
If the G parameter to [sqlite3_open_v2(F,D,G,V)] omits the
bit value [SQLITE_OPEN_CREATE] and the database does not
previously exist, an error is returned.

HLR H12714 S40200
If the G parameter to [sqlite3_open_v2(F,D,G,V)] contains the
bit value [SQLITE_OPEN_CREATE] and the database does not
previously exist, then an attempt is made to create and
initialize the database.

HLR H12717 S40200
If the filename argument to [sqlite3_open()], [sqlite3_open16()],
or [sqlite3_open_v2()] is ":memory:", then an private,
ephemeral, in-memory database is created for the connection.
<todo>Is SQLITE_OPEN_CREATE|SQLITE_OPEN_READWRITE required
in sqlite3_open_v2()?</todo>

HLR H12719 S40200
If the filename is NULL or an empty string, then a private,
ephemeral on-disk database will be created.
<todo>Is SQLITE_OPEN_CREATE|SQLITE_OPEN_READWRITE required
in sqlite3_open_v2()?</todo>

HLR H12721 S40200
The [database connection] created by [sqlite3_open_v2(F,D,G,V)]
will use the [sqlite3_vfs] object identified by the V parameter,
or the default [sqlite3_vfs] object if V is a NULL pointer.

HLR H12723 S40200
Two [database connections] will share a common cache if both were
opened with the same VFS while [shared cache mode] was enabled and
if both filenames compare equal using memcmp() after having been
processed by the [sqlite3_vfs | xFullPathname] method of the VFS.

HLR H12760 S20600
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_limit(sqlite3*, int id, int newVal);
</pre></blockquote>

HLR H12762 S20600
A successful call to [sqlite3_limit(D,C,V)] where V is
positive changes the limit on the size of construct C in the
[database connection] D to the lesser of V and the hard upper
bound on the size of C that is set at compile-time.

HLR H12766 S20600
A successful call to [sqlite3_limit(D,C,V)] where V is negative
leaves the state of the [database connection] D unchanged.

HLR H12769 S20600
A successful call to [sqlite3_limit(D,C,V)] returns the
value of the limit on the size of construct C in the
[database connection] D as it was prior to the call.

HLR H12790 H12760
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_LIMIT_LENGTH                    0
#define SQLITE_LIMIT_SQL_LENGTH                1
#define SQLITE_LIMIT_COLUMN                    2
#define SQLITE_LIMIT_EXPR_DEPTH                3
#define SQLITE_LIMIT_COMPOUND_SELECT           4
#define SQLITE_LIMIT_VDBE_OP                   5
#define SQLITE_LIMIT_FUNCTION_ARG              6
#define SQLITE_LIMIT_ATTACHED                  7
#define SQLITE_LIMIT_LIKE_PATTERN_LENGTH       8
#define SQLITE_LIMIT_VARIABLE_NUMBER           9
</pre></blockquote>

HLR H12800 S60200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_errcode(sqlite3 *db);
int sqlite3_extended_errcode(sqlite3 *db);
const char *sqlite3_errmsg(sqlite3*);
const void *sqlite3_errmsg16(sqlite3*);
</pre></blockquote>

HLR H12801 S60200
The [sqlite3_errcode(D)] interface returns the numeric
[result code] or [extended result code] for the most recently
failed interface call associated with the [database connection] D.

HLR H12802 S60200
The [sqlite3_extended_errcode(D)] interface returns the numeric
[extended result code] for the most recently
failed interface call associated with the [database connection] D.

HLR H12803 S60200
The [sqlite3_errmsg(D)] and [sqlite3_errmsg16(D)]
interfaces return English-language text that describes
the error in the mostly recently failed interface call,
encoded as either UTF-8 or UTF-16 respectively.

HLR H12807 S60200
The strings returned by [sqlite3_errmsg()] and [sqlite3_errmsg16()]
are valid until the next SQLite interface call.

HLR H12808 S60200
Calls to API routines that do not return an error code
(example: [sqlite3_data_count()]) do not
change the error code or message returned by
[sqlite3_errcode()], [sqlite3_extended_errcode()],
[sqlite3_errmsg()], or [sqlite3_errmsg16()].

HLR H12809 S60200
Interfaces that are not associated with a specific
[database connection] (examples:
[sqlite3_mprintf()] or [sqlite3_enable_shared_cache()]
do not change the values returned by
[sqlite3_errcode()], [sqlite3_extended_errcode()],
[sqlite3_errmsg()], or [sqlite3_errmsg16()].

HLR H12850 S60300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_table_column_metadata(
sqlite3 *db,                /* Connection handle */
const char *zDbName,        /* Database name or NULL */
const char *zTableName,     /* Table name */
const char *zColumnName,    /* Column name */
char const **pzDataType,    /* OUTPUT: Declared data type */
char const **pzCollSeq,     /* OUTPUT: Collation sequence name */
int *pNotNull,              /* OUTPUT: True if NOT NULL constraint exists */
int *pPrimaryKey,           /* OUTPUT: True if column part of PK */
int *pAutoinc               /* OUTPUT: True if column is auto-increment */
);
</pre></blockquote>

HLR H12910 S60400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);
</pre></blockquote>

HLR H12911 S60400
The callback function registered by sqlite3_progress_handler()
is invoked periodically during long running calls to
[sqlite3_step()].

HLR H12912 S60400
The progress callback is invoked once for every N virtual
machine opcodes, where N is the second argument to
the [sqlite3_progress_handler()] call that registered
the callback.  If N is less than 1, sqlite3_progress_handler()
acts as if a NULL progress handler had been specified.

HLR H12913 S60400
The progress callback itself is identified by the third
argument to sqlite3_progress_handler().

HLR H12914 S60400
The fourth argument to sqlite3_progress_handler() is a
void pointer passed to the progress callback
function each time it is invoked.

HLR H12915 S60400
If a call to [sqlite3_step()] results in fewer than N opcodes
being executed, then the progress callback is never invoked.

HLR H12916 S60400
Every call to [sqlite3_progress_handler()]
overwrites any previously registered progress handler.

HLR H12917 S60400
If the progress handler callback is NULL then no progress
handler is invoked.

HLR H12918 S30500 S60400
If the progress callback returns a result other than 0, then
the behavior is a if [sqlite3_interrupt()] had been called.

HLR H12930 S60200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_get_autocommit(sqlite3*);
</pre></blockquote>

HLR H12931 S60200
The [sqlite3_get_autocommit(D)] interface returns non-zero or
zero if the [database connection] D is or is not in autocommit
mode, respectively.

HLR H12932 S60200
Autocommit mode is on by default.

HLR H12933 S60200
Autocommit mode is disabled by a successful [BEGIN] statement.

HLR H12934 S60200
Autocommit mode is enabled by a successful [COMMIT] or [ROLLBACK]
statement.

HLR H12950 S60400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_commit_hook(sqlite3*, int(*)(void*), void*);
void *sqlite3_rollback_hook(sqlite3*, void(*)(void *), void*);
</pre></blockquote>

HLR H12951 S60400
The [sqlite3_commit_hook(D,F,P)] interface registers the
callback function F to be invoked with argument P whenever
a transaction commits on the [database connection] D.

HLR H12952 S60400
The [sqlite3_commit_hook(D,F,P)] interface returns the P argument
from the previous call with the same [database connection] D,
or NULL on the first call for a particular database connection D.

HLR H12953 S60400
Each call to [sqlite3_commit_hook()] overwrites the callback
registered by prior calls.

HLR H12954 S60400
If the F argument to [sqlite3_commit_hook(D,F,P)] is NULL
then the commit hook callback is canceled and no callback
is invoked when a transaction commits.

HLR H12955 S60400
If the commit callback returns non-zero then the commit is
converted into a rollback.

HLR H12961 S60400
The [sqlite3_rollback_hook(D,F,P)] interface registers the
callback function F to be invoked with argument P whenever
a transaction rolls back on the [database connection] D.

HLR H12962 S60400
The [sqlite3_rollback_hook(D,F,P)] interface returns the P
argument from the previous call with the same
[database connection] D, or NULL on the first call
for a particular database connection D.

HLR H12963 S60400
Each call to [sqlite3_rollback_hook()] overwrites the callback
registered by prior calls.

HLR H12964 S60400
If the F argument to [sqlite3_rollback_hook(D,F,P)] is NULL
then the rollback hook callback is canceled and no callback
is invoked when a transaction rolls back.

HLR H12970 S60400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_update_hook(
sqlite3*,
void(*)(void *,int ,char const *,char const *,sqlite3_int64),
void*
);
</pre></blockquote>

HLR H12971 S60400
The [sqlite3_update_hook(D,F,P)] interface causes the callback
function F to be invoked with first parameter P whenever
a table row is modified, inserted, or deleted on
the [database connection] D.

HLR H12973 S60400
The [sqlite3_update_hook(D,F,P)] interface returns the value
of P for the previous call on the same [database connection] D,
or NULL for the first call.

HLR H12975 S60400
If the update hook callback F in [sqlite3_update_hook(D,F,P)]
is NULL then the no update callbacks are made.

HLR H12977 S60400
Each call to [sqlite3_update_hook(D,F,P)] overrides prior calls
to the same interface on the same [database connection] D.

HLR H12979 S60400
The update hook callback is not invoked when internal system
tables such as sqlite_master and sqlite_sequence are modified.

HLR H12981 S60400
The second parameter to the update callback
is one of [SQLITE_INSERT], [SQLITE_DELETE] or [SQLITE_UPDATE],
depending on the operation that caused the callback to be invoked.

HLR H12983 S60400
The third and fourth arguments to the callback contain pointers
to zero-terminated UTF-8 strings which are the names of the
database and table that is being updated.

HLR H12985 S60400
The final callback parameter is the rowid of the row after
the change occurs.

HLR H13000 H13010
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_stmt sqlite3_stmt;
</pre></blockquote>

HLR H13010 S10000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_prepare(
sqlite3 *db,            /* Database handle */
const char *zSql,       /* SQL statement, UTF-8 encoded */
int nByte,              /* Maximum length of zSql in bytes. */
sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
const char **pzTail     /* OUT: Pointer to unused portion of zSql */
);
int sqlite3_prepare_v2(
sqlite3 *db,            /* Database handle */
const char *zSql,       /* SQL statement, UTF-8 encoded */
int nByte,              /* Maximum length of zSql in bytes. */
sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
const char **pzTail     /* OUT: Pointer to unused portion of zSql */
);
int sqlite3_prepare16(
sqlite3 *db,            /* Database handle */
const void *zSql,       /* SQL statement, UTF-16 encoded */
int nByte,              /* Maximum length of zSql in bytes. */
sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
const void **pzTail     /* OUT: Pointer to unused portion of zSql */
);
int sqlite3_prepare16_v2(
sqlite3 *db,            /* Database handle */
const void *zSql,       /* SQL statement, UTF-16 encoded */
int nByte,              /* Maximum length of zSql in bytes. */
sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
const void **pzTail     /* OUT: Pointer to unused portion of zSql */
);
</pre></blockquote>

HLR H13011 S10000
The [sqlite3_prepare(db,zSql,...)] and
[sqlite3_prepare_v2(db,zSql,...)] interfaces interpret the
text in their zSql parameter as UTF-8.

HLR H13012 S10000
The [sqlite3_prepare16(db,zSql,...)] and
[sqlite3_prepare16_v2(db,zSql,...)] interfaces interpret the
text in their zSql parameter as UTF-16 in the native byte order.

HLR H13013 S10000
If the nByte argument to [sqlite3_prepare_v2(db,zSql,nByte,...)]
and its variants is less than zero, the SQL text is
read from zSql is read up to the first zero terminator.

HLR H13014 S10000
If the nByte argument to [sqlite3_prepare_v2(db,zSql,nByte,...)]
and its variants is non-negative, then at most nBytes bytes of
SQL text is read from zSql.

HLR H13015 S10000
In [sqlite3_prepare_v2(db,zSql,N,P,pzTail)] and its variants
if the zSql input text contains more than one SQL statement
and pzTail is not NULL, then *pzTail is made to point to the
first byte past the end of the first SQL statement in zSql.
<todo>What does *pzTail point to if there is one statement?</todo>

HLR H13016 S10000
A successful call to [sqlite3_prepare_v2(db,zSql,N,ppStmt,...)]
or one of its variants writes into *ppStmt a pointer to a new
[prepared statement] or a pointer to NULL if zSql contains
nothing other than whitespace or comments.

HLR H13019 S10000
The [sqlite3_prepare_v2()] interface and its variants return
[SQLITE_OK] or an appropriate [error code] upon failure.

HLR H13021 S10000
Before [sqlite3_prepare(db,zSql,nByte,ppStmt,pzTail)] or its
variants returns an error (any value other than [SQLITE_OK]),
they first set *ppStmt to NULL.

HLR H13100 H13000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const char *sqlite3_sql(sqlite3_stmt *pStmt);
</pre></blockquote>

HLR H13101 H13000
If the [prepared statement] passed as the argument to
[sqlite3_sql()] was compiled using either [sqlite3_prepare_v2()] or
[sqlite3_prepare16_v2()], then [sqlite3_sql()] returns
a pointer to a zero-terminated string containing a UTF-8 rendering
of the original SQL statement.

HLR H13102 H13000
If the [prepared statement] passed as the argument to
[sqlite3_sql()] was compiled using either [sqlite3_prepare()] or
[sqlite3_prepare16()], then [sqlite3_sql()] returns a NULL pointer.

HLR H13103 H13000
The string returned by [sqlite3_sql(S)] is valid until the
[prepared statement] S is deleted using [sqlite3_finalize(S)].

HLR H13120 S60600
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3 *sqlite3_db_handle(sqlite3_stmt*);
</pre></blockquote>

HLR H13123 S60600
The [sqlite3_db_handle(S)] interface returns a pointer
to the [database connection] associated with the
[prepared statement] S.

HLR H13140 S60600
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3_stmt *sqlite3_next_stmt(sqlite3 *pDb, sqlite3_stmt *pStmt);
</pre></blockquote>

HLR H13143 S60600
If D is a [database connection] that holds one or more
unfinalized [prepared statements] and S is a NULL pointer,
then [sqlite3_next_stmt(D, S)] routine shall return a pointer
to one of the prepared statements associated with D.

HLR H13146 S60600
If D is a [database connection] that holds no unfinalized
[prepared statements] and S is a NULL pointer, then
[sqlite3_next_stmt(D, S)] routine shall return a NULL pointer.

HLR H13149 S60600
If S is a [prepared statement] in the [database connection] D
and S is not the last prepared statement in D, then
[sqlite3_next_stmt(D, S)] routine shall return a pointer
to the next prepared statement in D after S.

HLR H13152 S60600
If S is the last [prepared statement] in the
[database connection] D then the [sqlite3_next_stmt(D, S)]
routine shall return a NULL pointer.

HLR H13200 S10000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_step(sqlite3_stmt*);
</pre></blockquote>

HLR H13202 S10000
If the [prepared statement] S is ready to be run, then
[sqlite3_step(S)] advances that prepared statement until
completion or until it is ready to return another row of the
result set, or until an [sqlite3_interrupt | interrupt]
or a run-time error occurs.

HLR H13300 S70300 S30100
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_finalize(sqlite3_stmt *pStmt);
</pre></blockquote>

HLR H13330 S70300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_reset(sqlite3_stmt *pStmt);
</pre></blockquote>

HLR H13500 S70300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
int sqlite3_bind_double(sqlite3_stmt*, int, double);
int sqlite3_bind_int(sqlite3_stmt*, int, int);
int sqlite3_bind_int64(sqlite3_stmt*, int, sqlite3_int64);
int sqlite3_bind_null(sqlite3_stmt*, int);
int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*));
int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int, void(*)(void*));
int sqlite3_bind_value(sqlite3_stmt*, int, const sqlite3_value*);
int sqlite3_bind_zeroblob(sqlite3_stmt*, int, int n);
</pre></blockquote>

HLR H13506 S70300
The [SQL statement compiler] recognizes tokens of the forms
"?", "?NNN", "$VVV", ":VVV", and "@VVV" as SQL parameters,
where NNN is any sequence of one or more digits
and where VVV is any sequence of one or more alphanumeric
characters or "::" optionally followed by a string containing
no spaces and contained within parentheses.

HLR H13509 S70300
The initial value of an SQL parameter is NULL.

HLR H13512 S70300
The index of an "?" SQL parameter is one larger than the
largest index of SQL parameter to the left, or 1 if
the "?" is the leftmost SQL parameter.

HLR H13515 S70300
The index of an "?NNN" SQL parameter is the integer NNN.

HLR H13518 S70300
The index of an ":VVV", "$VVV", or "@VVV" SQL parameter is
the same as the index of leftmost occurrences of the same
parameter, or one more than the largest index over all
parameters to the left if this is the first occurrence
of this parameter, or 1 if this is the leftmost parameter.

HLR H13521 S70300
The [SQL statement compiler] fails with an [SQLITE_RANGE]
error if the index of an SQL parameter is less than 1
or greater than the compile-time SQLITE_MAX_VARIABLE_NUMBER
parameter.

HLR H13524 S70300
Calls to [sqlite3_bind_text | sqlite3_bind(S,N,V,...)]
associate the value V with all SQL parameters having an
index of N in the [prepared statement] S.

HLR H13527 S70300
Calls to [sqlite3_bind_text | sqlite3_bind(S,N,...)]
override prior calls with the same values of S and N.

HLR H13530 S70300
Bindings established by [sqlite3_bind_text | sqlite3_bind(S,...)]
persist across calls to [sqlite3_reset(S)].

HLR H13533 S70300
In calls to [sqlite3_bind_blob(S,N,V,L,D)],
[sqlite3_bind_text(S,N,V,L,D)], or
[sqlite3_bind_text16(S,N,V,L,D)] SQLite binds the first L
bytes of the BLOB or string pointed to by V, when L
is non-negative.

HLR H13536 S70300
In calls to [sqlite3_bind_text(S,N,V,L,D)] or
[sqlite3_bind_text16(S,N,V,L,D)] SQLite binds characters
from V through the first zero character when L is negative.

HLR H13539 S70300
In calls to [sqlite3_bind_blob(S,N,V,L,D)],
[sqlite3_bind_text(S,N,V,L,D)], or
[sqlite3_bind_text16(S,N,V,L,D)] when D is the special
constant [SQLITE_STATIC], SQLite assumes that the value V
is held in static unmanaged space that will not change
during the lifetime of the binding.

HLR H13542 S70300
In calls to [sqlite3_bind_blob(S,N,V,L,D)],
[sqlite3_bind_text(S,N,V,L,D)], or
[sqlite3_bind_text16(S,N,V,L,D)] when D is the special
constant [SQLITE_TRANSIENT], the routine makes a
private copy of the value V before it returns.

HLR H13545 S70300
In calls to [sqlite3_bind_blob(S,N,V,L,D)],
[sqlite3_bind_text(S,N,V,L,D)], or
[sqlite3_bind_text16(S,N,V,L,D)] when D is a pointer to
a function, SQLite invokes that function to destroy the
value V after it has finished using the value V.

HLR H13548 S70300
In calls to [sqlite3_bind_zeroblob(S,N,V,L)] the value bound
is a BLOB of L bytes, or a zero-length BLOB if L is negative.

HLR H13551 S70300
In calls to [sqlite3_bind_value(S,N,V)] the V argument may
be either a [protected sqlite3_value] object or an
[unprotected sqlite3_value] object.

HLR H13600 S70300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_bind_parameter_count(sqlite3_stmt*);
</pre></blockquote>

HLR H13601 S70300
The [sqlite3_bind_parameter_count(S)] interface returns
the largest index of all SQL parameters in the
[prepared statement] S, or 0 if S contains no SQL parameters.

HLR H13620 S70300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const char *sqlite3_bind_parameter_name(sqlite3_stmt*, int);
</pre></blockquote>

HLR H13621 S70300
The [sqlite3_bind_parameter_name(S,N)] interface returns
a UTF-8 rendering of the name of the SQL parameter in
the [prepared statement] S having index N, or
NULL if there is no SQL parameter with index N or if the
parameter with index N is an anonymous parameter "?".

HLR H13640 S70300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_bind_parameter_index(sqlite3_stmt*, const char *zName);
</pre></blockquote>

HLR H13641 S70300
The [sqlite3_bind_parameter_index(S,N)] interface returns
the index of SQL parameter in the [prepared statement]
S whose name matches the UTF-8 string N, or 0 if there is
no match.

HLR H13660 S70300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_clear_bindings(sqlite3_stmt*);
</pre></blockquote>

HLR H13661 S70300
The [sqlite3_clear_bindings(S)] interface resets all SQL
parameter bindings in the [prepared statement] S back to NULL.

HLR H13710 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_column_count(sqlite3_stmt *pStmt);
</pre></blockquote>

HLR H13711 S10700
The [sqlite3_column_count(S)] interface returns the number of
columns in the result set generated by the [prepared statement] S,
or 0 if S does not generate a result set.

HLR H13720 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const char *sqlite3_column_name(sqlite3_stmt*, int N);
const void *sqlite3_column_name16(sqlite3_stmt*, int N);
</pre></blockquote>

HLR H13721 S10700
A successful invocation of the [sqlite3_column_name(S,N)]
interface returns the name of the Nth column (where 0 is
the leftmost column) for the result set of the
[prepared statement] S as a zero-terminated UTF-8 string.

HLR H13723 S10700
A successful invocation of the [sqlite3_column_name16(S,N)]
interface returns the name of the Nth column (where 0 is
the leftmost column) for the result set of the
[prepared statement] S as a zero-terminated UTF-16 string
in the native byte order.

HLR H13724 S10700
The [sqlite3_column_name()] and [sqlite3_column_name16()]
interfaces return a NULL pointer if they are unable to
allocate memory to hold their normal return strings.

HLR H13725 S10700
If the N parameter to [sqlite3_column_name(S,N)] or
[sqlite3_column_name16(S,N)] is out of range, then the
interfaces return a NULL pointer.

HLR H13726 S10700
The strings returned by [sqlite3_column_name(S,N)] and
[sqlite3_column_name16(S,N)] are valid until the next
call to either routine with the same S and N parameters
or until [sqlite3_finalize(S)] is called.

HLR H13727 S10700
When a result column of a [SELECT] statement contains
an AS clause, the name of that column is the identifier
to the right of the AS keyword.

HLR H13740 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const char *sqlite3_column_database_name(sqlite3_stmt*,int);
const void *sqlite3_column_database_name16(sqlite3_stmt*,int);
const char *sqlite3_column_table_name(sqlite3_stmt*,int);
const void *sqlite3_column_table_name16(sqlite3_stmt*,int);
const char *sqlite3_column_origin_name(sqlite3_stmt*,int);
const void *sqlite3_column_origin_name16(sqlite3_stmt*,int);
</pre></blockquote>

HLR H13741 S10700
The [sqlite3_column_database_name(S,N)] interface returns either
the UTF-8 zero-terminated name of the database from which the
Nth result column of the [prepared statement] S is extracted,
or NULL if the Nth column of S is a general expression
or if unable to allocate memory to store the name.

HLR H13742 S10700
The [sqlite3_column_database_name16(S,N)] interface returns either
the UTF-16 native byte order zero-terminated name of the database
from which the Nth result column of the [prepared statement] S is
extracted, or NULL if the Nth column of S is a general expression
or if unable to allocate memory to store the name.

HLR H13743 S10700
The [sqlite3_column_table_name(S,N)] interface returns either
the UTF-8 zero-terminated name of the table from which the
Nth result column of the [prepared statement] S is extracted,
or NULL if the Nth column of S is a general expression
or if unable to allocate memory to store the name.

HLR H13744 S10700
The [sqlite3_column_table_name16(S,N)] interface returns either
the UTF-16 native byte order zero-terminated name of the table
from which the Nth result column of the [prepared statement] S is
extracted, or NULL if the Nth column of S is a general expression
or if unable to allocate memory to store the name.

HLR H13745 S10700
The [sqlite3_column_origin_name(S,N)] interface returns either
the UTF-8 zero-terminated name of the table column from which the
Nth result column of the [prepared statement] S is extracted,
or NULL if the Nth column of S is a general expression
or if unable to allocate memory to store the name.

HLR H13746 S10700
The [sqlite3_column_origin_name16(S,N)] interface returns either
the UTF-16 native byte order zero-terminated name of the table
column from which the Nth result column of the
[prepared statement] S is extracted, or NULL if the Nth column
of S is a general expression or if unable to allocate memory
to store the name.

HLR H13748 S10700
The return values from
[sqlite3_column_database_name | column metadata interfaces]
are valid for the lifetime of the [prepared statement]
or until the encoding is changed by another metadata
interface call for the same prepared statement and column.

HLR H13760 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const char *sqlite3_column_decltype(sqlite3_stmt*,int);
const void *sqlite3_column_decltype16(sqlite3_stmt*,int);
</pre></blockquote>

HLR H13761 S10700
A successful call to [sqlite3_column_decltype(S,N)] returns a
zero-terminated UTF-8 string containing the declared datatype
of the table column that appears as the Nth column (numbered
from 0) of the result set to the [prepared statement] S.

HLR H13762 S10700
A successful call to [sqlite3_column_decltype16(S,N)]
returns a zero-terminated UTF-16 native byte order string
containing the declared datatype of the table column that appears
as the Nth column (numbered from 0) of the result set to the
[prepared statement] S.

HLR H13763 S10700
If N is less than 0 or N is greater than or equal to
the number of columns in the [prepared statement] S,
or if the Nth column of S is an expression or subquery rather
than a table column, or if a memory allocation failure
occurs during encoding conversions, then
calls to [sqlite3_column_decltype(S,N)] or
[sqlite3_column_decltype16(S,N)] return NULL.

HLR H13770 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_data_count(sqlite3_stmt *pStmt);
</pre></blockquote>

HLR H13771 S10700
After a call to [sqlite3_step(S)] that returns [SQLITE_ROW],
the [sqlite3_data_count(S)] routine will return the same value
as the [sqlite3_column_count(S)] function.

HLR H13772 S10700
After [sqlite3_step(S)] has returned any value other than
[SQLITE_ROW] or before [sqlite3_step(S)] has been called on the
[prepared statement] for the first time since it was
[sqlite3_prepare | prepared] or [sqlite3_reset | reset],
the [sqlite3_data_count(S)] routine returns zero.

HLR H13800 S10700
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const void *sqlite3_column_blob(sqlite3_stmt*, int iCol);
int sqlite3_column_bytes(sqlite3_stmt*, int iCol);
int sqlite3_column_bytes16(sqlite3_stmt*, int iCol);
double sqlite3_column_double(sqlite3_stmt*, int iCol);
int sqlite3_column_int(sqlite3_stmt*, int iCol);
sqlite3_int64 sqlite3_column_int64(sqlite3_stmt*, int iCol);
const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);
const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);
int sqlite3_column_type(sqlite3_stmt*, int iCol);
sqlite3_value *sqlite3_column_value(sqlite3_stmt*, int iCol);
</pre></blockquote>

HLR H13803 S10700
The [sqlite3_column_blob(S,N)] interface converts the
Nth column in the current row of the result set for
the [prepared statement] S into a BLOB and then returns a
pointer to the converted value.

HLR H13806 S10700
The [sqlite3_column_bytes(S,N)] interface returns the
number of bytes in the BLOB or string (exclusive of the
zero terminator on the string) that was returned by the
most recent call to [sqlite3_column_blob(S,N)] or
[sqlite3_column_text(S,N)].

HLR H13809 S10700
The [sqlite3_column_bytes16(S,N)] interface returns the
number of bytes in the string (exclusive of the
zero terminator on the string) that was returned by the
most recent call to [sqlite3_column_text16(S,N)].

HLR H13812 S10700
The [sqlite3_column_double(S,N)] interface converts the
Nth column in the current row of the result set for the
[prepared statement] S into a floating point value and
returns a copy of that value.

HLR H13815 S10700
The [sqlite3_column_int(S,N)] interface converts the
Nth column in the current row of the result set for the
[prepared statement] S into a 64-bit signed integer and
returns the lower 32 bits of that integer.

HLR H13818 S10700
The [sqlite3_column_int64(S,N)] interface converts the
Nth column in the current row of the result set for the
[prepared statement] S into a 64-bit signed integer and
returns a copy of that integer.

HLR H13821 S10700
The [sqlite3_column_text(S,N)] interface converts the
Nth column in the current row of the result set for
the [prepared statement] S into a zero-terminated UTF-8
string and returns a pointer to that string.

HLR H13824 S10700
The [sqlite3_column_text16(S,N)] interface converts the
Nth column in the current row of the result set for the
[prepared statement] S into a zero-terminated 2-byte
aligned UTF-16 native byte order string and returns
a pointer to that string.

HLR H13827 S10700
The [sqlite3_column_type(S,N)] interface returns
one of [SQLITE_NULL], [SQLITE_INTEGER], [SQLITE_FLOAT],
[SQLITE_TEXT], or [SQLITE_BLOB] as appropriate for
the Nth column in the current row of the result set for
the [prepared statement] S.

HLR H13830 S10700
The [sqlite3_column_value(S,N)] interface returns a
pointer to an [unprotected sqlite3_value] object for the
Nth column in the current row of the result set for
the [prepared statement] S.

HLR H14100 S20000 S30200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_config(int, ...);
</pre></blockquote>

HLR H14103 S20000
A successful invocation of [sqlite3_config()] shall return
[SQLITE_OK].

HLR H14106 S20000
The [sqlite3_config()] interface shall return [SQLITE_MISUSE]
if it is invoked in between calls to [sqlite3_initialize()] and
[sqlite3_shutdown()].

HLR H14120 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_SINGLETHREAD])
shall set the default [threading mode] to Single-thread.

HLR H14123 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_MULTITHREAD])
shall set the default [threading mode] to Multi-thread.

HLR H14126 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_SERIALIZED])
shall set the default [threading mode] to Serialized.

HLR H14129 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_MUTEX],X)
where X is a pointer to an initialized [sqlite3_mutex_methods]
object shall cause all subsequent mutex operations performed
by SQLite to use the mutex methods that were present in X
during the call to [sqlite3_config()].

HLR H14132 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_GETMUTEX],X)
where X is a pointer to an [sqlite3_mutex_methods] object
shall overwrite the content of [sqlite3_mutex_methods] object
with the mutex methods currently in use by SQLite.

HLR H14135 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_MALLOC],M)
where M is a pointer to an initialized [sqlite3_mem_methods]
object shall cause all subsequent memory allocation operations
performed by SQLite to use the methods that were present in
M during the call to [sqlite3_config()].

HLR H14138 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_GETMALLOC],M)
where M is a pointer to an [sqlite3_mem_methods] object shall
overwrite the content of [sqlite3_mem_methods] object with
the memory allocation methods currently in use by
SQLite.

HLR H14141 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_MEMSTATUS],1)
shall enable the memory allocation status collection logic.

HLR H14144 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_MEMSTATUS],0)
shall disable the memory allocation status collection logic.

HLR H14147 S20000
The memory allocation status collection logic shall be
enabled by default.

HLR H14150 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_SCRATCH],S,Z,N)
where Z and N are non-negative integers and
S is a pointer to an aligned memory buffer not less than
Z*N bytes in size shall cause S to be used by the
[scratch memory allocator] for as many as N simulataneous
allocations each of size Z.

HLR H14153 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_SCRATCH],S,Z,N)
where S is a NULL pointer shall disable the
[scratch memory allocator].

HLR H14156 S20000
A successful call to
[sqlite3_config]([SQLITE_CONFIG_PAGECACHE],S,Z,N)
where Z and N are non-negative integers and
S is a pointer to an aligned memory buffer not less than
Z*N bytes in size shall cause S to be used by the
[pagecache memory allocator] for as many as N simulataneous
allocations each of size Z.

HLR H14159 S20000
A successful call to
[sqlite3_config]([SQLITE_CONFIG_PAGECACHE],S,Z,N)
where S is a NULL pointer shall disable the
[pagecache memory allocator].

HLR H14162 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_HEAP],H,Z,N)
where Z and N are non-negative integers and
H is a pointer to an aligned memory buffer not less than
Z bytes in size shall enable the [memsys5] memory allocator
and cause it to use buffer S as its memory source and to use
a minimum allocation size of N.

HLR H14165 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_HEAP],H,Z,N)
where H is a NULL pointer shall disable the
[memsys5] memory allocator.

HLR H14168 S20000
A successful call to [sqlite3_config]([SQLITE_CONFIG_LOOKASIDE],Z,N)
shall cause the default [lookaside memory allocator] configuration
for new [database connections] to be N slots of Z bytes each.

HLR H14200 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_db_config(sqlite3*, int op, ...);
</pre></blockquote>

HLR H14203 S20000
A call to [sqlite3_db_config(D,V,...)] shall return [SQLITE_OK]
if and only if the call is successful.

HLR H14206 S20000
If one or more slots of the [lookaside memory allocator] for
[database connection] D are in use, then a call to
[sqlite3_db_config](D,[SQLITE_DBCONFIG_LOOKASIDE],...) shall
fail with an [SQLITE_BUSY] return code.

HLR H14209 S20000
A successful call to
[sqlite3_db_config](D,[SQLITE_DBCONFIG_LOOKASIDE],B,Z,N) where
D is an open [database connection] and Z and N are positive
integers and B is an aligned buffer at least Z*N bytes in size
shall cause the [lookaside memory allocator] for D to use buffer B
with N slots of Z bytes each.

HLR H14212 S20000
A successful call to
[sqlite3_db_config](D,[SQLITE_DBCONFIG_LOOKASIDE],B,Z,N) where
D is an open [database connection] and Z and N are positive
integers and B is NULL pointer shall cause the
[lookaside memory allocator] for D to a obtain Z*N byte buffer
from the primary memory allocator and use that buffer
with N lookaside slots of Z bytes each.

HLR H14215 S20000
A successful call to
[sqlite3_db_config](D,[SQLITE_DBCONFIG_LOOKASIDE],B,Z,N) where
D is an open [database connection] and Z and N are zero shall
disable the [lookaside memory allocator] for D.

HLR H15000 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct Mem sqlite3_value;
</pre></blockquote>

HLR H15100 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
const void *sqlite3_value_blob(sqlite3_value*);
int sqlite3_value_bytes(sqlite3_value*);
int sqlite3_value_bytes16(sqlite3_value*);
double sqlite3_value_double(sqlite3_value*);
int sqlite3_value_int(sqlite3_value*);
sqlite3_int64 sqlite3_value_int64(sqlite3_value*);
const unsigned char *sqlite3_value_text(sqlite3_value*);
const void *sqlite3_value_text16(sqlite3_value*);
const void *sqlite3_value_text16le(sqlite3_value*);
const void *sqlite3_value_text16be(sqlite3_value*);
int sqlite3_value_type(sqlite3_value*);
int sqlite3_value_numeric_type(sqlite3_value*);
</pre></blockquote>

HLR H15103 S20200
The [sqlite3_value_blob(V)] interface converts the
[protected sqlite3_value] object V into a BLOB and then
returns a pointer to the converted value.

HLR H15106 S20200
The [sqlite3_value_bytes(V)] interface returns the
number of bytes in the BLOB or string (exclusive of the
zero terminator on the string) that was returned by the
most recent call to [sqlite3_value_blob(V)] or
[sqlite3_value_text(V)].

HLR H15109 S20200
The [sqlite3_value_bytes16(V)] interface returns the
number of bytes in the string (exclusive of the
zero terminator on the string) that was returned by the
most recent call to [sqlite3_value_text16(V)],
[sqlite3_value_text16be(V)], or [sqlite3_value_text16le(V)].

HLR H15112 S20200
The [sqlite3_value_double(V)] interface converts the
[protected sqlite3_value] object V into a floating point value and
returns a copy of that value.

HLR H15115 S20200
The [sqlite3_value_int(V)] interface converts the
[protected sqlite3_value] object V into a 64-bit signed integer and
returns the lower 32 bits of that integer.

HLR H15118 S20200
The [sqlite3_value_int64(V)] interface converts the
[protected sqlite3_value] object V into a 64-bit signed integer and
returns a copy of that integer.

HLR H15121 S20200
The [sqlite3_value_text(V)] interface converts the
[protected sqlite3_value] object V into a zero-terminated UTF-8
string and returns a pointer to that string.

HLR H15124 S20200
The [sqlite3_value_text16(V)] interface converts the
[protected sqlite3_value] object V into a zero-terminated 2-byte
aligned UTF-16 native byte order
string and returns a pointer to that string.

HLR H15127 S20200
The [sqlite3_value_text16be(V)] interface converts the
[protected sqlite3_value] object V into a zero-terminated 2-byte
aligned UTF-16 big-endian
string and returns a pointer to that string.

HLR H15130 S20200
The [sqlite3_value_text16le(V)] interface converts the
[protected sqlite3_value] object V into a zero-terminated 2-byte
aligned UTF-16 little-endian
string and returns a pointer to that string.

HLR H15133 S20200
The [sqlite3_value_type(V)] interface returns
one of [SQLITE_NULL], [SQLITE_INTEGER], [SQLITE_FLOAT],
[SQLITE_TEXT], or [SQLITE_BLOB] as appropriate for
the [sqlite3_value] object V.

HLR H15136 S20200
The [sqlite3_value_numeric_type(V)] interface converts
the [protected sqlite3_value] object V into either an integer or
a floating point value if it can do so without loss of
information, and returns one of [SQLITE_NULL],
[SQLITE_INTEGER], [SQLITE_FLOAT], [SQLITE_TEXT], or
[SQLITE_BLOB] as appropriate for the
[protected sqlite3_value] object V after the conversion attempt.

HLR H15304 S10000
When a call to [sqlite3_step(S)] causes the [prepared statement]
S to run to completion, the function returns [SQLITE_DONE].

HLR H15306 S10000
When a call to [sqlite3_step(S)] stops because it is ready to
return another row of the result set, it returns [SQLITE_ROW].

HLR H15308 S10000
If a call to [sqlite3_step(S)] encounters an
[sqlite3_interrupt | interrupt] or a run-time error,
it returns an appropriate error code that is not one of
[SQLITE_OK], [SQLITE_ROW], or [SQLITE_DONE].

HLR H15310 S10000
If an [sqlite3_interrupt | interrupt] or a run-time error
occurs during a call to [sqlite3_step(S)]
for a [prepared statement] S created using
legacy interfaces [sqlite3_prepare()] or
[sqlite3_prepare16()], then the function returns either
[SQLITE_ERROR], [SQLITE_BUSY], or [SQLITE_MISUSE].

HLR H16001 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_context sqlite3_context;
</pre></blockquote>

HLR H16100 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_create_function(
sqlite3 *db,
const char *zFunctionName,
int nArg,
int eTextRep,
void *pApp,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
void (*xFinal)(sqlite3_context*)
);
int sqlite3_create_function16(
sqlite3 *db,
const void *zFunctionName,
int nArg,
int eTextRep,
void *pApp,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
void (*xFinal)(sqlite3_context*)
);
</pre></blockquote>

HLR H16103 S20200
The [sqlite3_create_function16(D,X,...)] interface shall behave
as [sqlite3_create_function(D,X,...)] in every way except that it
interprets the X argument as zero-terminated UTF-16
native byte order instead of as zero-terminated UTF-8.

HLR H16106 S20200
A successful invocation of the
[sqlite3_create_function(D,X,N,E,...)] interface shall register
or replaces callback functions in the [database connection] D
used to implement the SQL function named X with N parameters
and having a preferred text encoding of E.

HLR H16109 S20200
A successful call to [sqlite3_create_function(D,X,N,E,P,F,S,L)]
shall replace the P, F, S, and L values from any prior calls with
the same D, X, N, and E values.

HLR H16112 S20200
The [sqlite3_create_function(D,X,...)] interface shall fail
if the SQL function name X is
longer than 255 bytes exclusive of the zero terminator.

HLR H16118 S20200
The [sqlite3_create_function(D,X,N,E,P,F,S,L)] interface
shall fail unless either F is NULL and S and L are non-NULL or
F is non-NULL and S and L are NULL.

HLR H16121 S20200
The [sqlite3_create_function(D,...)] interface shall fails with an
error code of [SQLITE_BUSY] if there exist [prepared statements]
associated with the [database connection] D.

HLR H16124 S20200
The [sqlite3_create_function(D,X,N,...)] interface shall fail with
an error code of [SQLITE_ERROR] if parameter N is less
than -1 or greater than 127.

HLR H16127 S20200
When N is non-negative, the [sqlite3_create_function(D,X,N,...)]
interface shall register callbacks to be invoked for the
SQL function
named X when the number of arguments to the SQL function is
exactly N.

HLR H16130 S20200
When N is -1, the [sqlite3_create_function(D,X,N,...)]
interface shall register callbacks to be invoked for the SQL
function named X with any number of arguments.

HLR H16133 S20200
When calls to [sqlite3_create_function(D,X,N,...)]
specify multiple implementations of the same function X
and when one implementation has N>=0 and the other has N=(-1)
the implementation with a non-zero N shall be preferred.

HLR H16136 S20200
When calls to [sqlite3_create_function(D,X,N,E,...)]
specify multiple implementations of the same function X with
the same number of arguments N but with different
encodings E, then the implementation where E matches the
database encoding shall preferred.

HLR H16139 S20200
For an aggregate SQL function created using
[sqlite3_create_function(D,X,N,E,P,0,S,L)] the finalizer
function L shall always be invoked exactly once if the
step function S is called one or more times.

HLR H16142 S20200
When SQLite invokes either the xFunc or xStep function of
an application-defined SQL function or aggregate created
by [sqlite3_create_function()] or [sqlite3_create_function16()],
then the array of [sqlite3_value] objects passed as the
third parameter shall be [protected sqlite3_value] objects.

HLR H16210 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_aggregate_context(sqlite3_context*, int nBytes);
</pre></blockquote>

HLR H16211 S20200
The first invocation of [sqlite3_aggregate_context(C,N)] for
a particular instance of an aggregate function (for a particular
context C) causes SQLite to allocate N bytes of memory,
zero that memory, and return a pointer to the allocated memory.

HLR H16213 S20200
If a memory allocation error occurs during
[sqlite3_aggregate_context(C,N)] then the function returns 0.

HLR H16215 S20200
Second and subsequent invocations of
[sqlite3_aggregate_context(C,N)] for the same context pointer C
ignore the N parameter and return a pointer to the same
block of memory returned by the first invocation.

HLR H16217 S20200
The memory allocated by [sqlite3_aggregate_context(C,N)] is
automatically freed on the next call to [sqlite3_reset()]
or [sqlite3_finalize()] for the [prepared statement] containing
the aggregate function associated with context C.

HLR H16240 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_user_data(sqlite3_context*);
</pre></blockquote>

HLR H16243 S20200
The [sqlite3_user_data(C)] interface returns a copy of the
P pointer from the [sqlite3_create_function(D,X,N,E,P,F,S,L)]
or [sqlite3_create_function16(D,X,N,E,P,F,S,L)] call that
registered the SQL function associated with [sqlite3_context] C.

HLR H16250 S60600 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3 *sqlite3_context_db_handle(sqlite3_context*);
</pre></blockquote>

HLR H16253 S60600
The [sqlite3_context_db_handle(C)] interface returns a copy of the
D pointer from the [sqlite3_create_function(D,X,N,E,P,F,S,L)]
or [sqlite3_create_function16(D,X,N,E,P,F,S,L)] call that
registered the SQL function associated with [sqlite3_context] C.

HLR H16270 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_get_auxdata(sqlite3_context*, int N);
void sqlite3_set_auxdata(sqlite3_context*, int N, void*, void (*)(void*));
</pre></blockquote>

HLR H16272 S20200
The [sqlite3_get_auxdata(C,N)] interface returns a pointer
to metadata associated with the Nth parameter of the SQL function
whose context is C, or NULL if there is no metadata associated
with that parameter.

HLR H16274 S20200
The [sqlite3_set_auxdata(C,N,P,D)] interface assigns a metadata
pointer P to the Nth parameter of the SQL function with context C.

HLR H16276 S20200
SQLite will invoke the destructor D with a single argument
which is the metadata pointer P following a call to
[sqlite3_set_auxdata(C,N,P,D)] when SQLite ceases to hold
the metadata.

HLR H16277 S20200
SQLite ceases to hold metadata for an SQL function parameter
when the value of that parameter changes.

HLR H16278 S20200
When [sqlite3_set_auxdata(C,N,P,D)] is invoked, the destructor
is called for any prior metadata associated with the same function
context C and parameter N.

HLR H16279 S20200
SQLite will call destructors for any metadata it is holding
in a particular [prepared statement] S when either
[sqlite3_reset(S)] or [sqlite3_finalize(S)] is called.

HLR H16342 S30220
The [sqlite3_release_memory(N)] returns the number
of bytes actually freed, which might be more or less
than the amount requested.

HLR H16351 S30220
The [sqlite3_soft_heap_limit(N)] interface places a soft limit
of N bytes on the amount of heap memory that may be allocated
using [sqlite3_malloc()] or [sqlite3_realloc()] at any point
in time.

HLR H16352 S30220
If a call to [sqlite3_malloc()] or [sqlite3_realloc()] would
cause the total amount of allocated memory to exceed the
soft heap limit, then [sqlite3_release_memory()] is invoked
in an attempt to reduce the memory usage prior to proceeding
with the memory allocation attempt.

HLR H16353 S30220
Calls to [sqlite3_malloc()] or [sqlite3_realloc()] that trigger
attempts to reduce memory usage through the soft heap limit
mechanism continue even if the attempt to reduce memory
usage is unsuccessful.

HLR H16354 S30220
A negative or zero value for N in a call to
[sqlite3_soft_heap_limit(N)] means that there is no soft
heap limit and [sqlite3_release_memory()] will only be
called when memory is completely exhausted.

HLR H16355 S30220
The default value for the soft heap limit is zero.

HLR H16358 S30220
Each call to [sqlite3_soft_heap_limit(N)] overrides the
values set by all prior calls.

HLR H16400 S20200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void sqlite3_result_blob(sqlite3_context*, const void*, int, void(*)(void*));
void sqlite3_result_double(sqlite3_context*, double);
void sqlite3_result_error(sqlite3_context*, const char*, int);
void sqlite3_result_error16(sqlite3_context*, const void*, int);
void sqlite3_result_error_toobig(sqlite3_context*);
void sqlite3_result_error_nomem(sqlite3_context*);
void sqlite3_result_error_code(sqlite3_context*, int);
void sqlite3_result_int(sqlite3_context*, int);
void sqlite3_result_int64(sqlite3_context*, sqlite3_int64);
void sqlite3_result_null(sqlite3_context*);
void sqlite3_result_text(sqlite3_context*, const char*, int, void(*)(void*));
void sqlite3_result_text16(sqlite3_context*, const void*, int, void(*)(void*));
void sqlite3_result_text16le(sqlite3_context*, const void*, int,void(*)(void*));
void sqlite3_result_text16be(sqlite3_context*, const void*, int,void(*)(void*));
void sqlite3_result_value(sqlite3_context*, sqlite3_value*);
void sqlite3_result_zeroblob(sqlite3_context*, int n);
</pre></blockquote>

HLR H16403 S20200
The default return value from any SQL function is NULL.

HLR H16406 S20200
The [sqlite3_result_blob(C,V,N,D)] interface changes the
return value of function C to be a BLOB that is N bytes
in length and with content pointed to by V.

HLR H16409 S20200
The [sqlite3_result_double(C,V)] interface changes the
return value of function C to be the floating point value V.

HLR H16412 S20200
The [sqlite3_result_error(C,V,N)] interface changes the return
value of function C to be an exception with error code
[SQLITE_ERROR] and a UTF-8 error message copied from V up to the
first zero byte or until N bytes are read if N is positive.

HLR H16415 S20200
The [sqlite3_result_error16(C,V,N)] interface changes the return
value of function C to be an exception with error code
[SQLITE_ERROR] and a UTF-16 native byte order error message
copied from V up to the first zero terminator or until N bytes
are read if N is positive.

HLR H16418 S20200
The [sqlite3_result_error_toobig(C)] interface changes the return
value of the function C to be an exception with error code
[SQLITE_TOOBIG] and an appropriate error message.

HLR H16421 S20200
The [sqlite3_result_error_nomem(C)] interface changes the return
value of the function C to be an exception with error code
[SQLITE_NOMEM] and an appropriate error message.

HLR H16424 S20200
The [sqlite3_result_error_code(C,E)] interface changes the return
value of the function C to be an exception with error code E.
The error message text is unchanged.

HLR H16427 S20200
The [sqlite3_result_int(C,V)] interface changes the
return value of function C to be the 32-bit integer value V.

HLR H16430 S20200
The [sqlite3_result_int64(C,V)] interface changes the
return value of function C to be the 64-bit integer value V.

HLR H16433 S20200
The [sqlite3_result_null(C)] interface changes the
return value of function C to be NULL.

HLR H16436 S20200
The [sqlite3_result_text(C,V,N,D)] interface changes the
return value of function C to be the UTF-8 string
V up to the first zero if N is negative
or the first N bytes of V if N is non-negative.

HLR H16439 S20200
The [sqlite3_result_text16(C,V,N,D)] interface changes the
return value of function C to be the UTF-16 native byte order
string V up to the first zero if N is negative
or the first N bytes of V if N is non-negative.

HLR H16442 S20200
The [sqlite3_result_text16be(C,V,N,D)] interface changes the
return value of function C to be the UTF-16 big-endian
string V up to the first zero if N is negative
or the first N bytes or V if N is non-negative.

HLR H16445 S20200
The [sqlite3_result_text16le(C,V,N,D)] interface changes the
return value of function C to be the UTF-16 little-endian
string V up to the first zero if N is negative
or the first N bytes of V if N is non-negative.

HLR H16448 S20200
The [sqlite3_result_value(C,V)] interface changes the
return value of function C to be the [unprotected sqlite3_value]
object V.

HLR H16451 S20200
The [sqlite3_result_zeroblob(C,N)] interface changes the
return value of function C to be an N-byte BLOB of all zeros.

HLR H16454 S20200
The [sqlite3_result_error()] and [sqlite3_result_error16()]
interfaces make a copy of their error message strings before
returning.

HLR H16457 S20200
If the D destructor parameter to [sqlite3_result_blob(C,V,N,D)],
[sqlite3_result_text(C,V,N,D)], [sqlite3_result_text16(C,V,N,D)],
[sqlite3_result_text16be(C,V,N,D)], or
[sqlite3_result_text16le(C,V,N,D)] is the constant [SQLITE_STATIC]
then no destructor is ever called on the pointer V and SQLite
assumes that V is immutable.

HLR H16460 S20200
If the D destructor parameter to [sqlite3_result_blob(C,V,N,D)],
[sqlite3_result_text(C,V,N,D)], [sqlite3_result_text16(C,V,N,D)],
[sqlite3_result_text16be(C,V,N,D)], or
[sqlite3_result_text16le(C,V,N,D)] is the constant
[SQLITE_TRANSIENT] then the interfaces makes a copy of the
content of V and retains the copy.

HLR H16463 S20200
If the D destructor parameter to [sqlite3_result_blob(C,V,N,D)],
[sqlite3_result_text(C,V,N,D)], [sqlite3_result_text16(C,V,N,D)],
[sqlite3_result_text16be(C,V,N,D)], or
[sqlite3_result_text16le(C,V,N,D)] is some value other than
the constants [SQLITE_STATIC] and [SQLITE_TRANSIENT] then
SQLite will invoke the destructor D with V as its only argument
when it has finished with the V value.

HLR H16600 S20300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_create_collation(
sqlite3*,
const char *zName,
int eTextRep,
void*,
int(*xCompare)(void*,int,const void*,int,const void*)
);
int sqlite3_create_collation_v2(
sqlite3*,
const char *zName,
int eTextRep,
void*,
int(*xCompare)(void*,int,const void*,int,const void*),
void(*xDestroy)(void*)
);
int sqlite3_create_collation16(
sqlite3*,
const void *zName,
int eTextRep,
void*,
int(*xCompare)(void*,int,const void*,int,const void*)
);
</pre></blockquote>

HLR H16603 S20300
A successful call to the
[sqlite3_create_collation_v2(B,X,E,P,F,D)] interface
registers function F as the comparison function used to
implement collation X on the [database connection] B for
databases having encoding E.

HLR H16604 S20300
SQLite understands the X parameter to
[sqlite3_create_collation_v2(B,X,E,P,F,D)] as a zero-terminated
UTF-8 string in which case is ignored for ASCII characters and
is significant for non-ASCII characters.

HLR H16606 S20300
Successive calls to [sqlite3_create_collation_v2(B,X,E,P,F,D)]
with the same values for B, X, and E, override prior values
of P, F, and D.

HLR H16609 S20300
If the destructor D in [sqlite3_create_collation_v2(B,X,E,P,F,D)]
is not NULL then it is called with argument P when the
collating function is dropped by SQLite.

HLR H16612 S20300
A collating function is dropped when it is overloaded.

HLR H16615 S20300
A collating function is dropped when the database connection
is closed using [sqlite3_close()].

HLR H16618 S20300
The pointer P in [sqlite3_create_collation_v2(B,X,E,P,F,D)]
is passed through as the first parameter to the comparison
function F for all subsequent invocations of F.

HLR H16621 S20300
A call to [sqlite3_create_collation(B,X,E,P,F)] is exactly
the same as a call to [sqlite3_create_collation_v2()] with
the same parameters and a NULL destructor.

HLR H16624 S20300
Following a [sqlite3_create_collation_v2(B,X,E,P,F,D)],
SQLite uses the comparison function F for all text comparison
operations on the [database connection] B on text values that
use the collating sequence named X.

HLR H16627 S20300
The [sqlite3_create_collation16(B,X,E,P,F)] works the same
as [sqlite3_create_collation(B,X,E,P,F)] except that the
collation name X is understood as UTF-16 in native byte order
instead of UTF-8.

HLR H16630 S20300
When multiple comparison functions are available for the same
collating sequence, SQLite chooses the one whose text encoding
requires the least amount of conversion from the default
text encoding of the database.

HLR H16700 S20300
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_collation_needed(
sqlite3*,
void*,
void(*)(void*,sqlite3*,int eTextRep,const char*)
);
int sqlite3_collation_needed16(
sqlite3*,
void*,
void(*)(void*,sqlite3*,int eTextRep,const void*)
);
</pre></blockquote>

HLR H16702 S20300
A successful call to [sqlite3_collation_needed(D,P,F)]
or [sqlite3_collation_needed16(D,P,F)] causes
the [database connection] D to invoke callback F with first
parameter P whenever it needs a comparison function for a
collating sequence that it does not know about.

HLR H16704 S20300
Each successful call to [sqlite3_collation_needed()] or
[sqlite3_collation_needed16()] overrides the callback registered
on the same [database connection] by prior calls to either
interface.

HLR H16706 S20300
The name of the requested collating function passed in the
4th parameter to the callback is in UTF-8 if the callback
was registered using [sqlite3_collation_needed()] and
is in UTF-16 native byte order if the callback was
registered using [sqlite3_collation_needed16()].

HLR H17000 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3_mutex *sqlite3_mutex_alloc(int);
void sqlite3_mutex_free(sqlite3_mutex*);
void sqlite3_mutex_enter(sqlite3_mutex*);
int sqlite3_mutex_try(sqlite3_mutex*);
void sqlite3_mutex_leave(sqlite3_mutex*);
</pre></blockquote>

HLR H17001 H17000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_MUTEX_FAST             0
#define SQLITE_MUTEX_RECURSIVE        1
#define SQLITE_MUTEX_STATIC_MASTER    2
#define SQLITE_MUTEX_STATIC_MEM       3  /* sqlite3_malloc() */
#define SQLITE_MUTEX_STATIC_MEM2      4  /* sqlite3_release_memory() */
#define SQLITE_MUTEX_STATIC_PRNG      5  /* sqlite3_random() */
#define SQLITE_MUTEX_STATIC_LRU       6  /* lru page list */
#define SQLITE_MUTEX_STATIC_LRU2      7  /* lru page list */
</pre></blockquote>

HLR H17002 H17000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3_mutex *sqlite3_db_mutex(sqlite3*);
</pre></blockquote>

HLR H17080 S20130 S30800
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_mutex_held(sqlite3_mutex*);
int sqlite3_mutex_notheld(sqlite3_mutex*);
</pre></blockquote>

HLR H17110 S20130
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_mutex sqlite3_mutex;
</pre></blockquote>

HLR H17120 S20130
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_mutex_methods sqlite3_mutex_methods;
struct sqlite3_mutex_methods {
int (*xMutexInit)(void);
int (*xMutexEnd)(void);
sqlite3_mutex *(*xMutexAlloc)(int);
void (*xMutexFree)(sqlite3_mutex *);
void (*xMutexEnter)(sqlite3_mutex *);
int (*xMutexTry)(sqlite3_mutex *);
void (*xMutexLeave)(sqlite3_mutex *);
int (*xMutexHeld)(sqlite3_mutex *);
int (*xMutexNotheld)(sqlite3_mutex *);
};
</pre></blockquote>

HLR H17200 S60200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_status(int op, int *pCurrent, int *pHighwater, int resetFlag);
</pre></blockquote>

HLR H17250 H17200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_STATUS_MEMORY_USED          0
#define SQLITE_STATUS_PAGECACHE_USED       1
#define SQLITE_STATUS_PAGECACHE_OVERFLOW   2
#define SQLITE_STATUS_SCRATCH_USED         3
#define SQLITE_STATUS_SCRATCH_OVERFLOW     4
#define SQLITE_STATUS_MALLOC_SIZE          5
#define SQLITE_STATUS_PARSER_STACK         6
#define SQLITE_STATUS_PAGECACHE_SIZE       7
#define SQLITE_STATUS_SCRATCH_SIZE         8
</pre></blockquote>

HLR H17300 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void *sqlite3_malloc(int);
void *sqlite3_realloc(void*, int);
void sqlite3_free(void*);
</pre></blockquote>

HLR H17303 S20000
The [sqlite3_malloc(N)] interface returns either a pointer to
a newly checked-out block of at least N bytes of memory
that is 8-byte aligned, or it returns NULL if it is unable
to fulfill the request.

HLR H17304 S20000
The [sqlite3_malloc(N)] interface returns a NULL pointer if
N is less than or equal to zero.

HLR H17305 S20000
The [sqlite3_free(P)] interface releases memory previously
returned from [sqlite3_malloc()] or [sqlite3_realloc()],
making it available for reuse.

HLR H17306 S20000
A call to [sqlite3_free(NULL)] is a harmless no-op.

HLR H17310 S20000
A call to [sqlite3_realloc(0,N)] is equivalent to a call
to [sqlite3_malloc(N)].

HLR H17312 S20000
A call to [sqlite3_realloc(P,0)] is equivalent to a call
to [sqlite3_free(P)].

HLR H17315 S20000
The SQLite core uses [sqlite3_malloc()], [sqlite3_realloc()],
and [sqlite3_free()] for all of its memory allocation and
deallocation needs.

HLR H17318 S20000
The [sqlite3_realloc(P,N)] interface returns either a pointer
to a block of checked-out memory of at least N bytes in size
that is 8-byte aligned, or a NULL pointer.

HLR H17321 S20000
When [sqlite3_realloc(P,N)] returns a non-NULL pointer, it first
copies the first K bytes of content from P into the newly
allocated block, where K is the lesser of N and the size of
the buffer P.

HLR H17322 S20000
When [sqlite3_realloc(P,N)] returns a non-NULL pointer, it first
releases the buffer P.

HLR H17323 S20000
When [sqlite3_realloc(P,N)] returns NULL, the buffer P is
not modified or released.

HLR H17340 S30220
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_release_memory(int);
</pre></blockquote>

HLR H17341 S30220
The [sqlite3_release_memory(N)] interface attempts to
free N bytes of heap memory by deallocating non-essential
memory allocations held by the database library.

HLR H17350 S30220
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void sqlite3_soft_heap_limit(int);
</pre></blockquote>

HLR H17370 S30210
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
sqlite3_int64 sqlite3_memory_used(void);
sqlite3_int64 sqlite3_memory_highwater(int resetFlag);
</pre></blockquote>

HLR H17371 S30210
The [sqlite3_memory_used()] routine returns the number of bytes
of memory currently outstanding (malloced but not freed).

HLR H17373 S30210
The [sqlite3_memory_highwater()] routine returns the maximum
value of [sqlite3_memory_used()] since the high-water mark
was last reset.

HLR H17374 S30210
The values returned by [sqlite3_memory_used()] and
[sqlite3_memory_highwater()] include any overhead
added by SQLite in its implementation of [sqlite3_malloc()],
but not overhead added by the any underlying system library
routines that [sqlite3_malloc()] may call.

HLR H17375 S30210
The memory high-water mark is reset to the current value of
[sqlite3_memory_used()] if and only if the parameter to
[sqlite3_memory_highwater()] is true.  The value returned
by [sqlite3_memory_highwater(1)] is the high-water mark
prior to the reset.

HLR H17390 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
void sqlite3_randomness(int N, void *P);
</pre></blockquote>

HLR H17392 S20000
The [sqlite3_randomness(N,P)] interface writes N bytes of
high-quality pseudo-randomness into buffer P.

HLR H17400 S70000 S20000
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
char *sqlite3_mprintf(const char*,...);
char *sqlite3_vmprintf(const char*, va_list);
char *sqlite3_snprintf(int,char*,const char*, ...);
</pre></blockquote>

HLR H17403 S70000
The [sqlite3_mprintf()] and [sqlite3_vmprintf()] interfaces
return either pointers to zero-terminated UTF-8 strings held in
memory obtained from [sqlite3_malloc()] or NULL pointers if
a call to [sqlite3_malloc()] fails.

HLR H17406 S70000
The [sqlite3_snprintf()] interface writes a zero-terminated
UTF-8 string into the buffer pointed to by the second parameter
provided that the first parameter is greater than zero.

HLR H17407 S70000
The [sqlite3_snprintf()] interface does not write slots of
its output buffer (the second parameter) outside the range
of 0 through N-1 (where N is the first parameter)
regardless of the length of the string
requested by the format specification.

HLR H17500 S60200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_db_status(sqlite3*, int op, int *pCur, int *pHiwtr, int resetFlg);
</pre></blockquote>

HLR H17520 H17500
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_DBSTATUS_LOOKASIDE_USED     0
</pre></blockquote>

HLR H17550 S60200
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_stmt_status(sqlite3_stmt*, int op,int resetFlg);
</pre></blockquote>

HLR H17570 H17550
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
#define SQLITE_STMTSTATUS_FULLSCAN_STEP     1
#define SQLITE_STMTSTATUS_SORT              2
</pre></blockquote>

HLR H17800 S30230
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
typedef struct sqlite3_blob sqlite3_blob;
</pre></blockquote>

HLR H17810 S30230
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_blob_open(
sqlite3*,
const char *zDb,
const char *zTable,
const char *zColumn,
sqlite3_int64 iRow,
int flags,
sqlite3_blob **ppBlob
);
</pre></blockquote>

HLR H17813 S30230
A successful invocation of the [sqlite3_blob_open(D,B,T,C,R,F,P)]
interface shall open an [sqlite3_blob] object P on the BLOB
in column C of the table T in the database B on
the [database connection] D.

HLR H17814 S30230
A successful invocation of [sqlite3_blob_open(D,...)] shall start
a new transaction on the [database connection] D if that
connection is not already in a transaction.

HLR H17816 S30230
The [sqlite3_blob_open(D,B,T,C,R,F,P)] interface shall open
the BLOB for read and write access if and only if the F
parameter is non-zero.

HLR H17819 S30230
The [sqlite3_blob_open()] interface shall return [SQLITE_OK] on
success and an appropriate [error code] on failure.

HLR H17821 S30230
If an error occurs during evaluation of [sqlite3_blob_open(D,...)]
then subsequent calls to [sqlite3_errcode(D)],
[sqlite3_extended_errcode()],
[sqlite3_errmsg(D)], and [sqlite3_errmsg16(D)] shall return
information appropriate for that error.

HLR H17824 S30230
If any column in the row that a [sqlite3_blob] has open is
changed by a separate [UPDATE] or [DELETE] statement or by
an [ON CONFLICT] side effect, then the [sqlite3_blob] shall
be marked as invalid.

HLR H17830 S30230
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_blob_close(sqlite3_blob *);
</pre></blockquote>

HLR H17833 S30230
The [sqlite3_blob_close(P)] interface closes an [sqlite3_blob]
object P previously opened using [sqlite3_blob_open()].

HLR H17836 S30230
Closing an [sqlite3_blob] object using
[sqlite3_blob_close()] shall cause the current transaction to
commit if there are no other open [sqlite3_blob] objects
or [prepared statements] on the same [database connection] and
the database connection is in [autocommit mode].

HLR H17839 S30230
The [sqlite3_blob_close(P)] interfaces shall close the
[sqlite3_blob] object P unconditionally, even if
[sqlite3_blob_close(P)] returns something other than [SQLITE_OK].

HLR H17840 S30230
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_blob_bytes(sqlite3_blob *);
</pre></blockquote>

HLR H17843 S30230
The [sqlite3_blob_bytes(P)] interface returns the size
in bytes of the BLOB that the [sqlite3_blob] object P
refers to.

HLR H17850 S30230
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_blob_read(sqlite3_blob *, void *Z, int N, int iOffset);
</pre></blockquote>

HLR H17853 S30230
A successful invocation of [sqlite3_blob_read(P,Z,N,X)]
shall reads N bytes of data out of the BLOB referenced by
[BLOB handle] P beginning at offset X and store those bytes
into buffer Z.

HLR H17856 S30230
In [sqlite3_blob_read(P,Z,N,X)] if the size of the BLOB
is less than N+X bytes, then the function shall leave the
Z buffer unchanged and return [SQLITE_ERROR].

HLR H17859 S30230
In [sqlite3_blob_read(P,Z,N,X)] if X or N is less than zero
then the function shall leave the Z buffer unchanged
and return [SQLITE_ERROR].

HLR H17862 S30230
The [sqlite3_blob_read(P,Z,N,X)] interface shall return [SQLITE_OK]
if N bytes are successfully read into buffer Z.

HLR H17863 S30230
If the [BLOB handle] P is expired and X and N are within bounds
then [sqlite3_blob_read(P,Z,N,X)] shall leave the Z buffer
unchanged and return [SQLITE_ABORT].

HLR H17865 S30230
If the requested read could not be completed,
the [sqlite3_blob_read(P,Z,N,X)] interface shall return an
appropriate [error code] or [extended error code].

HLR H17868 S30230
If an error occurs during evaluation of [sqlite3_blob_read(P,...)]
then subsequent calls to [sqlite3_errcode(D)],
[sqlite3_extended_errcode()],
[sqlite3_errmsg(D)], and [sqlite3_errmsg16(D)] shall return
information appropriate for that error, where D is the
[database connection] that was used to open the [BLOB handle] P.

HLR H17870 S30230
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_blob_write(sqlite3_blob *, const void *z, int n, int iOffset);
</pre></blockquote>

HLR H17873 S30230
A successful invocation of [sqlite3_blob_write(P,Z,N,X)]
shall write N bytes of data from buffer Z into the BLOB
referenced by [BLOB handle] P beginning at offset X into
the BLOB.

HLR H17874 S30230
In the absence of other overridding changes, the changes
written to a BLOB by [sqlite3_blob_write()] shall
remain in effect after the associated [BLOB handle] expires.

HLR H17875 S30230
If the [BLOB handle] P was opened for reading only then
an invocation of [sqlite3_blob_write(P,Z,N,X)] shall leave
the referenced BLOB unchanged and return [SQLITE_READONLY].

HLR H17876 S30230
If the size of the BLOB referenced by [BLOB handle] P is
less than N+X bytes then [sqlite3_blob_write(P,Z,N,X)] shall
leave the BLOB unchanged and return [SQLITE_ERROR].

HLR H17877 S30230
If the [BLOB handle] P is expired and X and N are within bounds
then [sqlite3_blob_read(P,Z,N,X)] shall leave the BLOB
unchanged and return [SQLITE_ABORT].

HLR H17879 S30230
If X or N are less than zero then [sqlite3_blob_write(P,Z,N,X)]
shall leave the BLOB referenced by [BLOB handle] P unchanged
and return [SQLITE_ERROR].

HLR H17882 S30230
The [sqlite3_blob_write(P,Z,N,X)] interface shall return
[SQLITE_OK] if N bytes where successfully written into the BLOB.

HLR H17885 S30230
If the requested write could not be completed,
the [sqlite3_blob_write(P,Z,N,X)] interface shall return an
appropriate [error code] or [extended error code].

HLR H17888 S30230
If an error occurs during evaluation of [sqlite3_blob_write(D,...)]
then subsequent calls to [sqlite3_errcode(D)],
[sqlite3_extended_errcode()],
[sqlite3_errmsg(D)], and [sqlite3_errmsg16(D)] shall return
information appropriate for that error.

HLR H18000 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
struct sqlite3_module {
int iVersion;
int (*xCreate)(sqlite3*, void *pAux,
int argc, const char *const*argv,
sqlite3_vtab **ppVTab, char**);
int (*xConnect)(sqlite3*, void *pAux,
int argc, const char *const*argv,
sqlite3_vtab **ppVTab, char**);
int (*xBestIndex)(sqlite3_vtab *pVTab, sqlite3_index_info*);
int (*xDisconnect)(sqlite3_vtab *pVTab);
int (*xDestroy)(sqlite3_vtab *pVTab);
int (*xOpen)(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor);
int (*xClose)(sqlite3_vtab_cursor*);
int (*xFilter)(sqlite3_vtab_cursor*, int idxNum, const char *idxStr,
int argc, sqlite3_value **argv);
int (*xNext)(sqlite3_vtab_cursor*);
int (*xEof)(sqlite3_vtab_cursor*);
int (*xColumn)(sqlite3_vtab_cursor*, sqlite3_context*, int);
int (*xRowid)(sqlite3_vtab_cursor*, sqlite3_int64 *pRowid);
int (*xUpdate)(sqlite3_vtab *, int, sqlite3_value **, sqlite3_int64 *);
int (*xBegin)(sqlite3_vtab *pVTab);
int (*xSync)(sqlite3_vtab *pVTab);
int (*xCommit)(sqlite3_vtab *pVTab);
int (*xRollback)(sqlite3_vtab *pVTab);
int (*xFindFunction)(sqlite3_vtab *pVtab, int nArg, const char *zName,
void (**pxFunc)(sqlite3_context*,int,sqlite3_value**),
void **ppArg);
int (*xRename)(sqlite3_vtab *pVtab, const char *zNew);
};
</pre></blockquote>

HLR H18010 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
struct sqlite3_vtab {
const sqlite3_module *pModule;  /* The module for this virtual table */
int nRef;                       /* Used internally */
char *zErrMsg;                  /* Error message from sqlite3_mprintf() */
/* Virtual table implementations will typically add additional fields */
};
</pre></blockquote>

HLR H18020 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
struct sqlite3_vtab_cursor {
sqlite3_vtab *pVtab;      /* Virtual table of this cursor */
/* Virtual table implementations will typically add additional fields */
};
</pre></blockquote>

HLR H18100 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
struct sqlite3_index_info {
/* Inputs */
int nConstraint;           /* Number of entries in aConstraint */
struct sqlite3_index_constraint {
int iColumn;              /* Column on left-hand side of constraint */
unsigned char op;         /* Constraint operator */
unsigned char usable;     /* True if this constraint is usable */
int iTermOffset;          /* Used internally - xBestIndex should ignore */
} *aConstraint;            /* Table of WHERE clause constraints */
int nOrderBy;              /* Number of terms in the ORDER BY clause */
struct sqlite3_index_orderby {
int iColumn;              /* Column number */
unsigned char desc;       /* True for DESC.  False for ASC. */
} *aOrderBy;               /* The ORDER BY clause */
/* Outputs */
struct sqlite3_index_constraint_usage {
int argvIndex;           /* if &gt;0, constraint is part of argv to xFilter */
unsigned char omit;      /* Do not code a test for this constraint */
} *aConstraintUsage;
int idxNum;                /* Number used to identify the index */
char *idxStr;              /* String, possibly obtained from sqlite3_malloc */
int needToFreeIdxStr;      /* Free idxStr using sqlite3_free() if true */
int orderByConsumed;       /* True if output is already ordered */
double estimatedCost;      /* Estimated cost of using this index */
};
#define SQLITE_INDEX_CONSTRAINT_EQ    2
#define SQLITE_INDEX_CONSTRAINT_GT    4
#define SQLITE_INDEX_CONSTRAINT_LE    8
#define SQLITE_INDEX_CONSTRAINT_LT    16
#define SQLITE_INDEX_CONSTRAINT_GE    32
#define SQLITE_INDEX_CONSTRAINT_MATCH 64
</pre></blockquote>

HLR H18200 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_create_module(
sqlite3 *db,               /* SQLite connection to register module with */
const char *zName,         /* Name of the module */
const sqlite3_module *,    /* Methods for the module */
void *                     /* Client data for xCreate/xConnect */
);
</pre></blockquote>

HLR H18210 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_create_module_v2(
sqlite3 *db,               /* SQLite connection to register module with */
const char *zName,         /* Name of the module */
const sqlite3_module *,    /* Methods for the module */
void *,                    /* Client data for xCreate/xConnect */
void(*xDestroy)(void*)     /* Module destructor function */
);
</pre></blockquote>

HLR H18280 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_declare_vtab(sqlite3*, const char *zCreateTable);
</pre></blockquote>

HLR H18300 S20400
The sqlite3.h header file shall define the
the following interfaces:
<blockquote><pre>
int sqlite3_overload_function(sqlite3*, const char *zFuncName, int nArg);
</pre></blockquote>

HLR H21001 
Except for the read operation required by H21007 and those reads made
as part of opening a read-only transaction, SQLite shall ensure that
a <i>database connection</i> has an open read-only or read/write
transaction when any data is read from the <i>database file</i>.

HLR H21002 
Aside from those read operations described by H21007 and H21XXX, SQLite
shall read data from the database file in aligned blocks of
<i>page-size</i> bytes, where <i>page-size</i> is the database page size
used by the database file.

HLR H21003 
While opening a <i>read-only transaction</i>, after successfully
obtaining a <i>shared lock</i> on the database file, SQLite shall
attempt to detect and roll back a <i>hot journal file</i> associated
with the same database file.

HLR H21004 
Assuming no errors have occured, then after attempting to detect and
roll back a <i>hot journal file</i>, if the <i>page cache</i> contains
any entries associated with the current <i>database connection</i>,
then SQLite shall validate the contents of the <i>page cache</i> by
testing the <i>file change counter</i>.  This procedure is known as
<i>cache validiation</i>.

HLR H21005 
If the cache validiate procedure prescribed by H21004 is required and
does not prove that the <i>page cache</i> entries associated with the
current <i>database connection</i> are valid, then SQLite shall discard
all entries associated with the current <i>database connection</i> from
the <i>page cache</i>.

HLR H21006 
When a new <i>database connection</i> is required, SQLite shall attempt
to open a file-handle on the database file. If the attempt fails, then
no new <i>database connection</i> is created and an error returned.

HLR H21007 
When a new <i>database connection</i> is required, after opening the
new file-handle, SQLite shall attempt to read the first 100 bytes
of the database file. If the attempt fails for any other reason than
that the opened file is less than 100 bytes in size, then
the file-handle is closed, no new <i>database connection</i> is created
and an error returned instead.

HLR H21008 
If the <i>database file header</i> is successfully read from a newly
opened database file, the connections <i>expected page-size</i> shall
be set to the value stored in the <i>page-size field</i> of the
database header.

HLR H21009 
If the <i>database file header</i> cannot be read from a newly opened
database file (because the file is less than 100 bytes in size), the
connections <i>expected page-size</i> shall be set to the compile time
value of the SQLITE_DEFAULT_PAGESIZE option.

HLR H21010 
When required to open a <i>read-only transaction</i> using a
<i>database connection</i>, SQLite shall first attempt to obtain
a <i>shared-lock</i> on the file-handle open on the database file.

HLR H21011 
If, while opening a <i>read-only transaction</i>, SQLite fails to obtain
the <i>shared-lock</i> on the database file, then the process is
abandoned, no transaction is opened and an error returned to the user.

HLR H21012 
If, while opening a <i>read-only transaction</i>, SQLite encounters
an error while attempting to detect or roll back a <i>hot journal
file</i>, then the <i>shared-lock</i> on the database file is released,
no transaction is opened and an error returned to the user.

HLR H21013 
When required to end a <i>read-only transaction</i>, SQLite shall
relinquish the <i>shared lock</i> held on the database file by
calling the xUnlock() method of the file-handle.

HLR H21014 
When required to attempt to detect a <i>hot-journal file</i>, SQLite
shall first use the xAccess() method of the VFS layer to check if a
journal file exists in the file-system.

HLR H21015 
When required to attempt to detect a <i>hot-journal file</i>, if the
call to xAccess() required by H21014 indicates that a journal file does
not exist, then SQLite shall conclude that there is no <i>hot-journal
file</i> in the file system and therefore that no <i>hot journal
rollback</i> is required.

HLR H21016 
When required to attempt to detect a <i>hot-journal file</i>, if the
call to xAccess() required by H21014 indicates that a journal file
is present, then the xCheckReservedLock() method of the database file
file-handle is invoked to determine whether or not some other
process is holding a <i>reserved</i> or greater lock on the database
file.

HLR H21017 
If the call to xCheckReservedLock() required by H21016 indicates that
some other <i>database connection</i> is holding a <i>reserved</i>
or greater lock on the database file, then SQLite shall conclude that
there is no <i>hot journal file</i>. In this case the attempt to detect
a <i>hot journal file</i> is concluded.

HLR H21018 
When a file-handle open on a database file is unlocked, if the
<i>page cache</i> contains one or more entries belonging to the
associated <i>database connection</i>, SQLite shall store the value
of the <i>file change counter</i> internally.

HLR H21019 
When required to perform <i>cache validation</i> as part of opening
a <i>read transaction</i>, SQLite shall read a 16 byte block
starting at byte offset 24 of the <i>database file</i> using the xRead()
method of the <i>database connections</i> file handle.

HLR H21020 
While performing <i>cache validation</i>, after loading the 16 byte
block as required by H21019, SQLite shall compare the 32-bit big-endian
integer stored in the first 4 bytes of the block to the most
recently stored value of the <i>file change counter</i> (see H21018).
If the values are not the same, then SQLite shall conclude that
the contents of the cache are invalid.

HLR H21021 
During the conclusion of a <i>read transaction</i>, before unlocking
the database file, SQLite shall set the connections
<i>expected page size</i> to the current database <i>page-size</i>.

HLR H21022 
As part of opening a new <i>read transaction</i>, immediately after
performing <i>cache validation</i>, if there is no data for database
page 1 in the <i>page cache</i>, SQLite shall read <i>N</i> bytes from
the start of the database file using the xRead() method of the
connections file handle, where <i>N</i> is the connections current
<i>expected page size</i> value.

HLR H21023 
If page 1 data is read as required by H21023, then the value of the
<i>page-size</i> field that appears in the database file header that
consumes the first 100 bytes of the read block is not the same as the
connections current <i>expected page size</i>, then the
<i>expected page size</i> is set to this value, the database file is
unlocked and the entire procedure to open a <i>read transaction</i>
is repeated.

HLR H21024 
If page 1 data is read as required by H21023, then the value of the
<i>page-size</i> field that appears in the database file header that
consumes the first 100 bytes of the read block is the same as the
connections current <i>expected page size</i>, then the block of data
read is stored in the <i>page cache</i> as page 1.

HLR H21027 
When required to <i>journal a database page</i>, SQLite shall first
append the <i>page number</i> of the page being journalled to the
<i>journal file</i>, formatted as a 4-byte big-endian unsigned integer,
using a single call to the xWrite method of the file-handle opened
on the journal file.

HLR H21028 
When required to <i>journal a database page</i>, if the attempt to
append the <i>page number</i> to the journal file is successful,
then the current page data (<i>page-size</i> bytes) shall be appended
to the journal file, using a single call to the xWrite method of the
file-handle opened on the journal file.

HLR H21029 
When required to <i>journal a database page</i>, if the attempt to
append the current page data to the journal file is successful,
then SQLite shall append a 4-byte big-endian integer checksum value
to the to the journal file, using a single call to the xWrite method
of the file-handle opened on the journal file.

HLR H21030 
The checksum value written to the <i>journal file</i> by the write
required by H21029 shall be equal to the sum of the <i>checksum
initializer</i> field stored in the <i>journal header</i> (H21070) and
every 200th byte of the page data, beginning with the
(<i>page-size</i> % 200)th byte.

HLR H21035 
When required to open a <i>write transaction</i> on the database,
SQLite shall first open a <i>read transaction</i>, if the <i>database
connection</i> in question has not already opened one.

HLR H21036 
When required to open a <i>write transaction</i> on the database, after
ensuring a <i>read transaction</i> has already been opened, SQLite
shall obtain a <i>reserved lock</i> on the database file by calling
the xLock method of the file-handle open on the database file.

HLR H21037 
When required to open a <i>write transaction</i> on the database, after
obtaining a <i>reserved lock</i> on the database file, SQLite shall
open a read/write file-handle on the corresponding <i>journal file</i>.

HLR H21038 
When required to open a <i>write transaction</i> on the database, after
opening a file-handle on the <i>journal file</i>, SQLite shall append
a <i>journal header</i> to the (currently empty) <i>journal file</i>.

HLR H21040 
When a <i>database connection</i> is closed, SQLite shall close the
associated file handle at the VFS level.

HLR H21042 
SQLite shall ensure that a <i>database connection</i> has an open
read-only or read/write transaction before using data stored in the <i>page
cache</i> to satisfy user queries.

HLR H21043 
When a <i>database connection</i> is closed, all associated <i>page
cache</i> entries shall be discarded.

HLR H21044 
If while attempting to detect a <i>hot-journal file</i> the call to
xCheckReservedLock() indicates that no process holds a <i>reserved</i>
or greater lock on the <i>database file</i>, then SQLite shall open
a file handle on the potentially hot journal file using the VFS xOpen()
method.

HLR H21045 
After successfully opening a file-handle on a potentially hot journal
file, SQLite shall query the file for its size in bytes using the
xFileSize() method of the open file handle.

HLR H21046 
If the size of a potentially hot journal file is revealed to be zero
bytes by a query required by H21045, then SQLite shall close the
file handle opened on the journal file and delete the journal file using
a call to the VFS xDelete() method. In this case SQLite shall conclude
that there is no <i>hot journal file</i>.

HLR H21047 
If the size of a potentially hot journal file is revealed to be greater
than zero bytes by a query required by H21045, then SQLite shall attempt
to upgrade the <i>shared lock</i> held by the <i>database connection</i>
on the <i>database file</i> directly to an <i>exclusive lock</i>.

HLR H21048 
If an attempt to upgrade to an <i>exclusive lock</i> prescribed by
H21047 fails for any reason, then SQLite shall release all locks held by
the <i>database connection</i> and close the file handle opened on the
<i>journal file</i>. The attempt to open a <i>read-only transaction</i>
shall be deemed to have failed and an error returned to the user.

HLR H21049 
If, as part of the <i>hot journal file</i> detection process, the
attempt to upgrade to an <i>exclusive lock</i> mandated by H21047 is
successful, then SQLite shall query the file-system using the xAccess()
method of the VFS implementation to test whether or not the journal
file is still present in the file-system.

HLR H21050 
If the xAccess() query required by H21049 reveals that the journal
file is still present in the file system, then SQLite shall conclude
that the journal file is a <i>hot journal file</i> that needs to
be rolled back. SQLite shall immediately begin <i>hot journal
rollback</i>.

HLR H21051 
If the call to xAccess() required by H21014 fails (due to an IO error or
similar), then SQLite shall abandon the attempt to open a <i>read-only
transaction</i>, relinquish the <i>shared lock</i> held on the database
file and return an error to the user.

HLR H21052 
If the call to xCheckReservedLock() required by H21016 fails (due to an
IO or other internal VFS error), then SQLite shall abandon the attempt
to open a <i>read-only transaction</i>, relinquish the <i>shared lock</i>
held on the database file and return an error to the user.

HLR H21053 
If the call to xOpen() required by H21044 fails (due to an IO or other
internal VFS error), then SQLite shall abandon the attempt to open a
<i>read-only transaction</i>, relinquish the <i>shared lock</i> held on
the database file and return an error to the user.

HLR H21054 
If the call to xFileSize() required by H21045 fails (due to an IO or
other internal VFS error), then SQLite shall abandon the attempt to open
a <i>read-only transaction</i>, relinquish the <i>shared lock</i> held on
the database file, close the file handle opened on the journal file and
return an error to the user.

HLR H21055 
If the call to xDelete() required by H21045 fails (due to an IO or
other internal VFS error), then SQLite shall abandon the attempt to open
a <i>read-only transaction</i>, relinquish the <i>shared lock</i> held on
the database file and return an error to the user.

HLR H21056 
If the call to xAccess() required by H21049 fails (due to an IO or
other internal VFS error), then SQLite shall abandon the attempt to open
a <i>read-only transaction</i>, relinquish the lock held on the
database file, close the file handle opened on the journal file and
return an error to the user.

HLR H21057 
If the call to xAccess() required by H21049 reveals that the journal
file is no longer present in the file system, then SQLite shall abandon
the attempt to open a <i>read-only transaction</i>, relinquish the
lock held on the database file, close the file handle opened on the
journal file and return an SQLITE_BUSY error to the user.

HLR H21058 
If an attempt to acquire a <i>reserved lock</i> prescribed by
requirement H21036 fails, then SQLite shall deem the attempt to
open a <i>write transaction</i> to have failed and return an error
to the user.

HLR H21059 
When required to modify the contents of an existing database page that
existed and was not a <i>free-list leaf page</i> when the <i>write
transaction</i> was opened, SQLite shall journal the page if it has not
already been journalled within the current <i>write transaction</i>.

HLR H21060 
When required to modify the contents of an existing database page,
SQLite shall update the cached version of the database page content
stored as part of the <i>page cache entry</i> associated with the page.

HLR H21061 
When required to append a new database page to the database file,
SQLite shall create a new <i>page cache entry</i> corresponding to
the new page and insert it into the <i>page cache</i>. The <i>dirty
flag</i> of the new <i>page cache entry</i> shall be set.

HLR H21062 
When required to truncate (remove) a database page that existed and was
not a <i>free-list leaf page</i> when the <i>write transaction</i> was
opened from the end of a database file, SQLite shall journal the page if
it has not already been journalled within the current <i>write
transaction</i>.

HLR H21063 
When required to truncate a database page from the end of the database
file, SQLite shall discard the associated <i>page cache entry</i>
from the page cache.

HLR H21064 
When required to purge a <i>non-writable dirty page</i> from the
<i>page cache</i>, SQLite shall <i>sync the journal file</i> before
proceding with the write operation required by H21067.

HLR H21066 
After <i>syncing the journal file</i> as required by H21064, SQLite
shall append a new <i>journal header</i> to the <i>journal file</i>
before proceding with the write operation required by H21067.

HLR H21067 
When required to purge a <i>page cache entry</i> that is a
<i>dirty page</i> SQLite shall write the page data into the database
file, using a single call to the xWrite method of the <i>database
connection</i> file handle.

HLR H21068 
When required to append a <i>journal header</i> to the <i>journal
file</i>, SQLite shall do so by writing a block of <i>sector-size</i>
bytes using a single call to the xWrite method of the file-handle
open on the <i>journal file</i>. The block of data written shall begin
at the smallest sector-size aligned offset at or following the current
end of the <i>journal file</i>.

HLR H21069 
The first 8 bytes of the <i>journal header</i> required to be written
by H21068 shall contain the following values, in order from byte offset 0
to 7: 0xd9, 0xd5, 0x05, 0xf9, 0x20, 0xa1, 0x63 and 0xd7.

HLR H21070 
Bytes 8-11 of the <i>journal header</i> required to be written by
H21068 shall contain 0x00.

HLR H21071 
Bytes 12-15 of the <i>journal header</i> required to be written by
H21068 shall contain the number of pages that the database file
contained when the current <i>write-transaction</i> was started,
formatted as a 4-byte big-endian unsigned integer.

HLR H21072 
Bytes 16-19 of the <i>journal header</i> required to be written by
H21068 shall contain pseudo-randomly generated values.

HLR H21073 
Bytes 20-23 of the <i>journal header</i> required to be written by
H21068 shall contain the <i>sector size</i> used by the VFS layer,
formatted as a 4-byte big-endian unsigned integer.

HLR H21074 
Bytes 24-27 of the <i>journal header</i> required to be written by
H21068 shall contain the <i>page size</i> used by the database at
the start of the <i>write transaction</i>, formatted as a 4-byte
big-endian unsigned integer.

HLR H21075 
When required to <i>sync the journal file</i>, SQLite shall invoke the
xSync method of the file handle open on the <i>journal file</i>.

HLR H21076 
When required to <i>sync the journal file</i>, after invoking the
xSync method as required by H21075, SQLite shall update the <i>record
count</i> of the <i>journal header</i> most recently written to the
<i>journal file</i>. The 4-byte field shall be updated to contain
the number of <i>journal records</i> that have been written to the
<i>journal file</i> since the <i>journal header</i> was written,
formatted as a 4-byte big-endian unsigned integer.

HLR H21077 
When required to <i>sync the journal file</i>, after updating the
<i>record count</i> field of a <i>journal header</i> as required by
H21076, SQLite shall invoke the xSync method of the file handle open
on the <i>journal file</i>.

HLR H21078 
When required to upgrade to an <i>exclusive lock</i> as part of a write
transaction, SQLite shall first attempt to obtain a <i>pending lock</i>
on the database file if one is not already held by invoking the xLock
method of the file handle opened on the <i>database file</i>.

HLR H21079 
When required to upgrade to an <i>exclusive lock</i> as part of a write
transaction, after successfully obtaining a <i>pending lock</i> SQLite
shall attempt to obtain an <i>exclusive lock</i> by invoking the
xLock method of the file handle opened on the <i>database file</i>.

HLR H21080 
When required to <i>commit a write-transaction</i>, SQLite shall
modify page 1 to increment the value stored in the <i>change counter</i>
field of the <i>database file header</i>.

HLR H21081 
When required to <i>commit a write-transaction</i>, after incrementing
the <i>change counter</i> field, SQLite shall <i>sync the journal
file</i>.

HLR H21082 
When required to <i>commit a write-transaction</i>, after <i>syncing
the journal file</i> as required by H21081, if an <i>exclusive lock</i>
on the database file is not already held, SQLite shall attempt to
<i>upgrade to an exclusive lock</i>.

HLR H21083 
When required to <i>commit a write-transaction</i>, after <i>syncing
the journal file</i> as required by H21081 and ensuring that an
<i>exclusive lock</i> is held on the database file as required by
H21083, SQLite shall copy the contents of all <i>dirty page</i>
stored in the <i>page cache</i> into the <i>database file</i> using
calls to the xWrite method of the <i>database connection</i> file
handle. Each call to xWrite shall write the contents of a single
<i>dirty page</i> (<i>page-size</i> bytes of data) to the database
file. Dirty pages shall be written in order of <i>page number</i>,
from lowest to highest.

HLR H21084 
When required to <i>commit a write-transaction</i>, after copying the
contents of any <i>dirty pages</i> to the database file as required
by H21083, SQLite shall sync the database file by invoking the xSync
method of the <i>database connection</i> file handle.

HLR H21085 
When required to <i>commit a write-transaction</i>, after syncing
the database file as required by H21084, SQLite shall close the
file-handle opened on the <i>journal file</i> and delete the
<i>journal file</i> from the file system via a call to the VFS
xDelete method.

HLR H21086 
When required to <i>commit a write-transaction</i>, after deleting
the <i>journal file</i> as required by H21085, SQLite shall relinquish
all locks held on the <i>database file</i> by invoking the xUnlock
method of the <i>database connection</i> file handle.