Index: images/faster-read-blobapi.jpg ================================================================== --- images/faster-read-blobapi.jpg +++ images/faster-read-blobapi.jpg cannot compute difference between binary files Index: images/faster-read-mmap.jpg ================================================================== --- images/faster-read-mmap.jpg +++ images/faster-read-mmap.jpg cannot compute difference between binary files Index: images/faster-read-sql.jpg ================================================================== --- images/faster-read-sql.jpg +++ images/faster-read-sql.jpg cannot compute difference between binary files Index: images/faster-write-safe.jpg ================================================================== --- images/faster-write-safe.jpg +++ images/faster-write-safe.jpg cannot compute difference between binary files Index: images/faster-write-unsafe.jpg ================================================================== --- images/faster-write-unsafe.jpg +++ images/faster-write-unsafe.jpg cannot compute difference between binary files ADDED misc/kvtest-timings.ods Index: misc/kvtest-timings.ods ================================================================== --- /dev/null +++ misc/kvtest-timings.ods cannot compute difference between binary files Index: pages/atomiccommit.in ================================================================== --- pages/atomiccommit.in +++ pages/atomiccommit.in @@ -65,11 +65,11 @@ interface layer that interrogates the underlying filesystem to find the true sector size. As currently implemented (version 3.5.0) this method still returns a hard-coded value of 512 bytes, since there is no standard way of discovering the true sector size on either Unix or Windows. But the method is available for embedded device - manufactures to tweak according to their own needs. And we have + manufacturers to tweak according to their own needs. And we have left open the possibility of filling in a more meaningful implementation on Unix and Windows in the future.

SQLite has traditionally assumed that a sector write is not atomic. However, SQLite does always assume that a sector write is linear. By "linear" Index: pages/capi3ref.in ================================================================== --- pages/capi3ref.in +++ pages/capi3ref.in @@ -232,11 +232,11 @@

These pages are intended to be precise and detailed specification. For a tutorial introduction, see instead:

This same content is also available as a single large HTML file.

Index: pages/changes.in ================================================================== --- pages/changes.in +++ pages/changes.in @@ -18,10 +18,19 @@ global nChng aChng xrefChng set aChng($nChng) [list $date $desc $options] set xrefChng($date) $nChng incr nChng } + +chng {2017-08-24 (3.20.1)} { +
  • Fix a potential memory leak in the new [sqlite3_result_pointer()] interface. + Ticket [https://sqlite.org/src/info/7486aa54b968e9b5|7486aa54b968e9b5]. +

    Hashes: +

  • SQLITE_SOURCE_ID: "2017-08-24 16:21:36 8d3a7ea6c5690d6b7c3767558f4f01b511c55463e3f9e64506801fe9b74dce34" +
  • SHA3-256 for sqlite3.c: 93b1a6d69b48dc39697d1d3a1e4c30b55da0bdd2cad0c054462f91081832954a +} {patchagainst 1} + chng {2017-08-01 (3.20.0)} {
  • Update the text of error messages returned by [sqlite3_errmsg()] for some error codes.
  • Add new [pointer passing interfaces]. Index: pages/chronology.in ================================================================== --- pages/chronology.in +++ pages/chronology.in @@ -26,10 +26,11 @@ # A small amount of manual editing and de-duplication followed. # # Manually edit the list for each subsequent release. # foreach line [split { +8d3a7ea6c5|2017-08-24|Version 3.20.1 9501e22dfe|2017-08-01|Version 3.20.0 036ebf729e|2017-06-17|Version 3.18.2 77bb46233d|2017-06-16|Version 3.18.1 0ee482a1e0|2017-06-08|Version 3.19.3 edb4e819b0|2017-05-25|Version 3.19.2 Index: pages/cintro.in ================================================================== --- pages/cintro.in +++ pages/cintro.in @@ -116,12 +116,12 @@ named [sqlite3_open()] when in fact there are three separate routines that accomplish the same thing in slightly different ways: [sqlite3_open()], [sqlite3_open16()] and [sqlite3_open_v2()]. The list mentions [sqlite3_column_int | sqlite3_column()] when in fact no such routine exists. - The "sqlite3_column()" shown in the list is place holders for - an entire family of routines to be used for extracting column + The "sqlite3_column()" shown in the list is a placeholder for + an entire family of routines that extra column data in various datatypes.

    Here is a summary of what the core interfaces do: @@ -223,11 +223,11 @@ files or to create and open new database files. While many applications use only a single [database connection], there is no reason why an application cannot call [sqlite3_open()] multiple times in order to open multiple [database connections] - either to the same database or to different databases. Sometimes a multi-threaded application - will create separate [database connections] for each threads. + will create separate [database connections] for each thread. Note that a single [database connection] can access two or more databases using the [ATTACH] SQL command, so it is not necessary to have a separate database connection for each database file.

    Index: pages/csv.in ================================================================== --- pages/csv.in +++ pages/csv.in @@ -18,11 +18,11 @@ implementing other virtual tables.

    -The CVS virtual table is not built into the SQLite amalgamation. +The CSV virtual table is not built into the SQLite amalgamation. It is available as a [https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/csv.c|separate source file] that can be compiled into a [loadable extension]. Typical usage of the CSV virtual table from the [command-line shell] would be something like this: @@ -81,14 +81,14 @@

    The data= argument specifies that TEXT is the literal content of the CSV file.

  • schema=SCHEMA

    The schema= argument specifies a [CREATE TABLE] statement that -the CVS virtual table passes to the [sqlite3_declare_vtab()] interface in +the CSV virtual table passes to the [sqlite3_declare_vtab()] interface in order to define the number and names of the columns in the virtual table. If both the schema= and the columns= arguments are omitted, -then the CVS virtual table reads the first row of the input content in order +then the CSV virtual table reads the first row of the input content in order to determine the number of columns and names the columns cNNN where NNN values are consecutive integers. It is not allowed to have both schema= and columns= arguments.

  • columns=N Index: pages/download.in ================================================================== --- pages/download.in +++ pages/download.in @@ -425,23 +425,23 @@ The [amalgamation] source code files (the "sqlite3.c" and "sqlite3.h" files) build products and are not contained in raw source code tree.

    -http://www.sqlite.org/cgi/src (Dallas)
    -http://www2.sqlite.org/cgi/src (Newark)
    -http://www3.sqlite.org/cgi/src (Fremont)
    +https://www.sqlite.org/cgi/src (Dallas)
    +https://www2.sqlite.org/cgi/src (Newark)
    +https://www3.sqlite.org/cgi/src (San Francisco)

    The documentation is maintained in separate [http://www.fossil-scm.org/ | Fossil] repositories located at:

    -http://www.sqlite.org/cgi/docsrc (Dallas)
    -http://www2.sqlite.org/cgi/docsrc (Newark)
    -http://www3.sqlite.org/cgi/docsrc (Fremont)
    +https://www.sqlite.org/cgi/docsrc (Dallas)
    +https://www2.sqlite.org/cgi/docsrc (Newark)
    +https://www3.sqlite.org/cgi/docsrc (San Francisco)
    proc set_download_hyperlinks {} { set script "