System.Data.SQLite

Check-in [3f3dcb7a07]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Update SQLite core library to the 3.11 release.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 3f3dcb7a07fb94faf53b52abfd6638d31823fa3b
User & Date: mistachkin 2016-02-16 08:08:56.517
Context
2016-02-16
08:12
Enable the 'dbstat' virtual table in the interop assembly. check-in: b48111dc00 user: mistachkin tags: trunk
08:08
Update SQLite core library to the 3.11 release. check-in: 3f3dcb7a07 user: mistachkin tags: trunk
2016-02-14
04:59
Fix test constraint for test 'vtab-1.12'. check-in: b07b77cc26 user: mistachkin tags: trunk
Changes
Unified Diff Ignore Whitespace Patch
Changes to Doc/Extra/Core/pragma.html.
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388











1389
1390
1391
1392
1393
1394



1395
1396
1397
1398
1399
1400
1401


1402
1403
1404
1405
1406
1407
1408

1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424



1425
1426
1427
1428
1429
1430
1431
    SQLite.  This pragma is subject to change without notice and is not
    recommended for use by application programs.</p>
  
<a name="pragma_synchronous"></a>
<hr>
    <p><b>PRAGMA </b><i>schema.</i><b>synchronous;
        <br>PRAGMA </b><i>schema.</i><b>synchronous = </b>
          <i>0 | OFF | 1 | NORMAL | 2 | FULL</i><b>;</b></p>

    <p>Query or change the setting of the "synchronous" flag.
    The first (query) form will return the synchronous setting as an 











    integer.  When synchronous is FULL (2), the SQLite database engine will
    use the xSync method of the <a href="vfs.html">VFS</a> to ensure that all content is safely
    written to the disk surface prior to continuing.
    This ensures that an operating system crash or power failure will
    not corrupt the database.
    FULL synchronous is very safe, but it is also slower. 



    When synchronous is NORMAL (1), the SQLite database
    engine will still sync at the most critical moments, but less often
    than in FULL mode.  There is a very small (though non-zero) chance that
    a power failure at just the wrong time could corrupt the database in
    NORMAL mode.  But in practice, you are more likely to suffer
    a catastrophic disk failure or some other unrecoverable hardware
    fault.


    With synchronous OFF (0), SQLite continues without syncing
    as soon as it has handed data off to the operating system.
    If the application running SQLite crashes, the data will be safe, but
    the database might become corrupted if the operating system
    crashes or the computer loses power before that data has been written
    to the disk surface.  On the other hand, some
    operations are as much as 50 or more times faster with synchronous OFF.

    </p>
 
    <p>In <a href="wal.html">WAL</a> mode when synchronous is NORMAL (1), the WAL file is
    synchronized before each <a href="wal.html#ckpt">checkpoint</a> and the database file is
    synchronized after each completed <a href="wal.html#ckpt">checkpoint</a> and the WAL file
    header is synchronized when a WAL file begins to be reused after
    a checkpoint, but no sync operations occur during most transactions.
    With synchronous=FULL in WAL mode, an additional
    sync operation of the WAL file happens after each transaction commit.
    The extra WAL sync following each transaction help ensure that 
    transactions are durable across a power loss, but they do not aid
    in preserving consistency.
    If durability is not a concern, then synchronous=NORMAL is normally
    all one needs in WAL mode.</p>

    <p>The default setting is synchronous=FULL.</p>




    <p>See also the <a href="pragma.html#pragma_fullfsync">fullfsync</a> and <a href="pragma.html#pragma_checkpoint_fullfsync">checkpoint_fullfsync</a> pragmas.</p>
<a name="pragma_table_info"></a>
<hr>
    <p><b>PRAGMA </b><i>schema.</i><b>table_info(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one row for each column in the named table.
    Columns in the result set include the column name,







|



>
>
>
>
>
>
>
>
>
>
>
|




|
>
>
>






|
>
>





|
|
>















|
>
>
>







1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
    SQLite.  This pragma is subject to change without notice and is not
    recommended for use by application programs.</p>
  
<a name="pragma_synchronous"></a>
<hr>
    <p><b>PRAGMA </b><i>schema.</i><b>synchronous;
        <br>PRAGMA </b><i>schema.</i><b>synchronous = </b>
          <i>0 | OFF | 1 | NORMAL | 2 | FULL | 3 | EXTRA</i><b>;</b></p>

    <p>Query or change the setting of the "synchronous" flag.
    The first (query) form will return the synchronous setting as an 
    integer.  The second form changes the synchronous setting.
    The meanings of the various synchronous settings are as follows:</p>
    <dl>
    <dt><b>EXTRA</b> (3)</dt>
    <dd>
    EXTRA synchronous is like FULL with the addition that the directory
    containing a <a href="lockingv3.html#rollback">rollback journal</a> is synced after that journal is unlinked
    to commit a transaction in DELETE mode.  EXTRA provides additional
    durability if the commit is followed closely by a power loss.</dd>
    <dt><b>FULL</b> (2)</dt>
    <dd>
    When synchronous is FULL (2), the SQLite database engine will
    use the xSync method of the <a href="vfs.html">VFS</a> to ensure that all content is safely
    written to the disk surface prior to continuing.
    This ensures that an operating system crash or power failure will
    not corrupt the database.
    FULL synchronous is very safe, but it is also slower.  FULL is the
    usual default setting when not in <a href="wal.html">WAL mode</a>.</dd>
    <dt><b>NORMAL</b> (1)</dt>
    <dd>
    When synchronous is NORMAL (1), the SQLite database
    engine will still sync at the most critical moments, but less often
    than in FULL mode.  There is a very small (though non-zero) chance that
    a power failure at just the wrong time could corrupt the database in
    NORMAL mode.  But in practice, you are more likely to suffer
    a catastrophic disk failure or some other unrecoverable hardware
    fault.  NORMAL is the default when in <a href="wal.html">WAL mode</a>.</dd>
    <dt><b>OFF</b> (0)</dt>
    <dd>
    With synchronous OFF (0), SQLite continues without syncing
    as soon as it has handed data off to the operating system.
    If the application running SQLite crashes, the data will be safe, but
    the database might become corrupted if the operating system
    crashes or the computer loses power before that data has been written
    to the disk surface.  On the other hand, commits can be orders of
    magnitude faster with synchronous OFF.
    </dd></dl>
    </p>
 
    <p>In <a href="wal.html">WAL</a> mode when synchronous is NORMAL (1), the WAL file is
    synchronized before each <a href="wal.html#ckpt">checkpoint</a> and the database file is
    synchronized after each completed <a href="wal.html#ckpt">checkpoint</a> and the WAL file
    header is synchronized when a WAL file begins to be reused after
    a checkpoint, but no sync operations occur during most transactions.
    With synchronous=FULL in WAL mode, an additional
    sync operation of the WAL file happens after each transaction commit.
    The extra WAL sync following each transaction help ensure that 
    transactions are durable across a power loss, but they do not aid
    in preserving consistency.
    If durability is not a concern, then synchronous=NORMAL is normally
    all one needs in WAL mode.</p>

    <p>The default setting is usually synchronous=FULL, 
    except in <a href="wal.html">WAL mode</a> when the default is synchronous=NORMAL.
    The <a href="compile.html#extra_durable">SQLITE_EXTRA_DURABLE</a> compile-time option changes the
    default to synchronous=EXTRA.</p>

    <p>See also the <a href="pragma.html#pragma_fullfsync">fullfsync</a> and <a href="pragma.html#pragma_checkpoint_fullfsync">checkpoint_fullfsync</a> pragmas.</p>
<a name="pragma_table_info"></a>
<hr>
    <p><b>PRAGMA </b><i>schema.</i><b>table_info(</b><i>table-name</i><b>);</b></p>
    <p>This pragma returns one row for each column in the named table.
    Columns in the result set include the column name,
Changes to Doc/Special/Core/vtab.html.
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
forms the reply. The <a href="c3ref/index_info.html">sqlite3_index_info</a> structure looks like this:

<blockquote><pre>
  struct sqlite3_index_info {
    /* Inputs */
    const int nConstraint;     /* Number of entries in aConstraint */
    const 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 */
    } *const aConstraint;      /* Table of WHERE clause constraints */
    const int nOrderBy;        /* Number of terms in the ORDER BY clause */
    const struct sqlite3_index_orderby {
       int iColumn;              /* Column number */







|







720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
forms the reply. The <a href="c3ref/index_info.html">sqlite3_index_info</a> structure looks like this:

<blockquote><pre>
  struct sqlite3_index_info {
    /* Inputs */
    const int nConstraint;     /* Number of entries in aConstraint */
    const struct sqlite3_index_constraint {
       int iColumn;              /* Column constrained.  -1 for ROWID */
       unsigned char op;         /* Constraint operator */
       unsigned char usable;     /* True if this constraint is usable */
       int iTermOffset;          /* Used internally - xBestIndex should ignore */
    } *const aConstraint;      /* Table of WHERE clause constraints */
    const int nOrderBy;        /* Number of terms in the ORDER BY clause */
    const struct sqlite3_index_orderby {
       int iColumn;              /* Column number */
Changes to SQLite.Interop/src/core/sqlite3.c.
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
**
** See also: [sqlite3_libversion()],
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
** [sqlite_version()] and [sqlite_source_id()].
*/
#define SQLITE_VERSION        "3.11.0"
#define SQLITE_VERSION_NUMBER 3011000
#define SQLITE_SOURCE_ID      "2016-02-13 18:54:10 37ec3015ec95035d31e3672f520908a0d36c9d67"

/*
** CAPI3REF: Run-Time Library Version Numbers
** KEYWORDS: sqlite3_version, sqlite3_sourceid
**
** These interfaces provide the same information as the [SQLITE_VERSION],
** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] C preprocessor macros







|







326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
**
** See also: [sqlite3_libversion()],
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
** [sqlite_version()] and [sqlite_source_id()].
*/
#define SQLITE_VERSION        "3.11.0"
#define SQLITE_VERSION_NUMBER 3011000
#define SQLITE_SOURCE_ID      "2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f"

/*
** CAPI3REF: Run-Time Library Version Numbers
** KEYWORDS: sqlite3_version, sqlite3_sourceid
**
** These interfaces provide the same information as the [SQLITE_VERSION],
** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] C preprocessor macros
54187
54188
54189
54190
54191
54192
54193

54194
54195
54196





54197
54198
54199
54200
54201
54202
54203
54204
    ** checksums must be recomputed when the transaction is committed.  */
    if( iFirst && (p->pDirty || isCommit==0) ){
      u32 iWrite = 0;
      VVA_ONLY(rc =) sqlite3WalFindFrame(pWal, p->pgno, &iWrite);
      assert( rc==SQLITE_OK || iWrite==0 );
      if( iWrite>=iFirst ){
        i64 iOff = walFrameOffset(iWrite, szPage) + WAL_FRAME_HDRSIZE;

        if( pWal->iReCksum==0 || iWrite<pWal->iReCksum ){
          pWal->iReCksum = iWrite;
        }





        rc = sqlite3OsWrite(pWal->pWalFd, p->pData, szPage, iOff);
        if( rc ) return rc;
        p->flags &= ~PGHDR_WAL_APPEND;
        continue;
      }
    }

    iFrame++;







>



>
>
>
>
>
|







54187
54188
54189
54190
54191
54192
54193
54194
54195
54196
54197
54198
54199
54200
54201
54202
54203
54204
54205
54206
54207
54208
54209
54210
    ** checksums must be recomputed when the transaction is committed.  */
    if( iFirst && (p->pDirty || isCommit==0) ){
      u32 iWrite = 0;
      VVA_ONLY(rc =) sqlite3WalFindFrame(pWal, p->pgno, &iWrite);
      assert( rc==SQLITE_OK || iWrite==0 );
      if( iWrite>=iFirst ){
        i64 iOff = walFrameOffset(iWrite, szPage) + WAL_FRAME_HDRSIZE;
        void *pData;
        if( pWal->iReCksum==0 || iWrite<pWal->iReCksum ){
          pWal->iReCksum = iWrite;
        }
#if defined(SQLITE_HAS_CODEC)
        if( (pData = sqlite3PagerCodec(p))==0 ) return SQLITE_NOMEM;
#else
        pData = p->pData;
#endif
        rc = sqlite3OsWrite(pWal->pWalFd, pData, szPage, iOff);
        if( rc ) return rc;
        p->flags &= ~PGHDR_WAL_APPEND;
        continue;
      }
    }

    iFrame++;
184345
184346
184347
184348
184349
184350
184351
184352
184353
184354
184355
184356
184357
184358
184359
static void fts5SourceIdFunc(
  sqlite3_context *pCtx,          /* Function call context */
  int nArg,                       /* Number of args */
  sqlite3_value **apUnused        /* Function arguments */
){
  assert( nArg==0 );
  UNUSED_PARAM2(nArg, apUnused);
  sqlite3_result_text(pCtx, "fts5: 2016-02-13 18:54:10 37ec3015ec95035d31e3672f520908a0d36c9d67", -1, SQLITE_TRANSIENT);
}

static int fts5Init(sqlite3 *db){
  static const sqlite3_module fts5Mod = {
    /* iVersion      */ 2,
    /* xCreate       */ fts5CreateMethod,
    /* xConnect      */ fts5ConnectMethod,







|







184351
184352
184353
184354
184355
184356
184357
184358
184359
184360
184361
184362
184363
184364
184365
static void fts5SourceIdFunc(
  sqlite3_context *pCtx,          /* Function call context */
  int nArg,                       /* Number of args */
  sqlite3_value **apUnused        /* Function arguments */
){
  assert( nArg==0 );
  UNUSED_PARAM2(nArg, apUnused);
  sqlite3_result_text(pCtx, "fts5: 2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f", -1, SQLITE_TRANSIENT);
}

static int fts5Init(sqlite3 *db){
  static const sqlite3_module fts5Mod = {
    /* iVersion      */ 2,
    /* xCreate       */ fts5CreateMethod,
    /* xConnect      */ fts5ConnectMethod,
Changes to SQLite.Interop/src/core/sqlite3.h.
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
**
** See also: [sqlite3_libversion()],
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
** [sqlite_version()] and [sqlite_source_id()].
*/
#define SQLITE_VERSION        "3.11.0"
#define SQLITE_VERSION_NUMBER 3011000
#define SQLITE_SOURCE_ID      "2016-02-13 18:54:10 37ec3015ec95035d31e3672f520908a0d36c9d67"

/*
** CAPI3REF: Run-Time Library Version Numbers
** KEYWORDS: sqlite3_version, sqlite3_sourceid
**
** These interfaces provide the same information as the [SQLITE_VERSION],
** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] C preprocessor macros







|







109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
**
** See also: [sqlite3_libversion()],
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
** [sqlite_version()] and [sqlite_source_id()].
*/
#define SQLITE_VERSION        "3.11.0"
#define SQLITE_VERSION_NUMBER 3011000
#define SQLITE_SOURCE_ID      "2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f"

/*
** CAPI3REF: Run-Time Library Version Numbers
** KEYWORDS: sqlite3_version, sqlite3_sourceid
**
** These interfaces provide the same information as the [SQLITE_VERSION],
** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] C preprocessor macros
Changes to SQLite.Interop/src/ext/fts5.c.
16526
16527
16528
16529
16530
16531
16532
16533
16534
16535
16536
16537
16538
16539
16540
static void fts5SourceIdFunc(
  sqlite3_context *pCtx,          /* Function call context */
  int nArg,                       /* Number of args */
  sqlite3_value **apUnused        /* Function arguments */
){
  assert( nArg==0 );
  UNUSED_PARAM2(nArg, apUnused);
  sqlite3_result_text(pCtx, "fts5: 2016-02-13 18:54:10 37ec3015ec95035d31e3672f520908a0d36c9d67", -1, SQLITE_TRANSIENT);
}

static int fts5Init(sqlite3 *db){
  static const sqlite3_module fts5Mod = {
    /* iVersion      */ 2,
    /* xCreate       */ fts5CreateMethod,
    /* xConnect      */ fts5ConnectMethod,







|







16526
16527
16528
16529
16530
16531
16532
16533
16534
16535
16536
16537
16538
16539
16540
static void fts5SourceIdFunc(
  sqlite3_context *pCtx,          /* Function call context */
  int nArg,                       /* Number of args */
  sqlite3_value **apUnused        /* Function arguments */
){
  assert( nArg==0 );
  UNUSED_PARAM2(nArg, apUnused);
  sqlite3_result_text(pCtx, "fts5: 2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f", -1, SQLITE_TRANSIENT);
}

static int fts5Init(sqlite3 *db){
  static const sqlite3_module fts5Mod = {
    /* iVersion      */ 2,
    /* xCreate       */ fts5CreateMethod,
    /* xConnect      */ fts5ConnectMethod,
Changes to System.Data.SQLite/ISQLiteNativeModule.cs.
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
        /// forms the reply. The sqlite3_index_info structure looks like this:
        /// </para>
        /// <para><code>
        ///   struct sqlite3_index_info {
        ///     /* Inputs */
        ///     const int nConstraint;     /* Number of entries in aConstraint */
        ///     const 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 */
        ///     } *const aConstraint;      /* Table of WHERE clause constraints */
        ///     const int nOrderBy;        /* Number of terms in the ORDER BY clause */
        ///     const struct sqlite3_index_orderby {
        ///        int iColumn;              /* Column number */







|







331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
        /// forms the reply. The sqlite3_index_info structure looks like this:
        /// </para>
        /// <para><code>
        ///   struct sqlite3_index_info {
        ///     /* Inputs */
        ///     const int nConstraint;     /* Number of entries in aConstraint */
        ///     const struct sqlite3_index_constraint {
        ///        int iColumn;              /* Column constrained.  -1 for ROWID */
        ///        unsigned char op;         /* Constraint operator */
        ///        unsigned char usable;     /* True if this constraint is usable */
        ///        int iTermOffset;          /* Used internally - xBestIndex should ignore */
        ///     } *const aConstraint;      /* Table of WHERE clause constraints */
        ///     const int nOrderBy;        /* Number of terms in the ORDER BY clause */
        ///     const struct sqlite3_index_orderby {
        ///        int iColumn;              /* Column number */