Upgrade SQLite to version 3053002
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -147,12 +147,12 @@ extern "C" {
|
|||||||
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
|
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
|
||||||
** [sqlite_version()] and [sqlite_source_id()].
|
** [sqlite_version()] and [sqlite_source_id()].
|
||||||
*/
|
*/
|
||||||
#define SQLITE_VERSION "3.53.0"
|
#define SQLITE_VERSION "3.53.2"
|
||||||
#define SQLITE_VERSION_NUMBER 3053000
|
#define SQLITE_VERSION_NUMBER 3053002
|
||||||
#define SQLITE_SOURCE_ID "2026-04-09 11:41:38 4525003a53a7fc63ca75c59b22c79608659ca12f0131f52c18637f829977f20b"
|
#define SQLITE_SOURCE_ID "2026-06-03 19:12:13 d6e03d8c777cfa2d35e3b60d8ec3e0187f3e9f99d8e2ee9cac695fd6fcdf1a24"
|
||||||
#define SQLITE_SCM_BRANCH "trunk"
|
#define SQLITE_SCM_BRANCH "branch-3.53"
|
||||||
#define SQLITE_SCM_TAGS "release major-release version-3.53.0"
|
#define SQLITE_SCM_TAGS "release version-3.53.2"
|
||||||
#define SQLITE_SCM_DATETIME "2026-04-09T11:41:38.498Z"
|
#define SQLITE_SCM_DATETIME "2026-06-03T19:12:13.350Z"
|
||||||
|
|
||||||
/*
|
/*
|
||||||
** CAPI3REF: Run-Time Library Version Numbers
|
** CAPI3REF: Run-Time Library Version Numbers
|
||||||
@@ -12854,11 +12854,23 @@ SQLITE_API int sqlite3changeset_apply_v3(
|
|||||||
** database behave as if they were declared with "ON UPDATE NO ACTION ON
|
** database behave as if they were declared with "ON UPDATE NO ACTION ON
|
||||||
** DELETE NO ACTION", even if they are actually CASCADE, RESTRICT, SET NULL
|
** DELETE NO ACTION", even if they are actually CASCADE, RESTRICT, SET NULL
|
||||||
** or SET DEFAULT.
|
** or SET DEFAULT.
|
||||||
|
**
|
||||||
|
** <dt>SQLITE_CHANGESETAPPLY_NOUPDATELOOP <dd>
|
||||||
|
** Sometimes, a changeset contains two or more update statements such that
|
||||||
|
** although after applying all updates the database will contain no
|
||||||
|
** constraint violations, no single update can be applied before the others.
|
||||||
|
** The simplest example of this is a pair of UPDATEs that have "swapped"
|
||||||
|
** two column values with a UNIQUE constraint.
|
||||||
|
** <p>
|
||||||
|
** Usually, sqlite3changeset_apply() and similar functions work hard to try
|
||||||
|
** to find a way to apply such a changeset. However, if this flag is set,
|
||||||
|
** then all such updates are considered CONSTRAINT conflicts.
|
||||||
*/
|
*/
|
||||||
#define SQLITE_CHANGESETAPPLY_NOSAVEPOINT 0x0001
|
#define SQLITE_CHANGESETAPPLY_NOSAVEPOINT 0x0001
|
||||||
#define SQLITE_CHANGESETAPPLY_INVERT 0x0002
|
#define SQLITE_CHANGESETAPPLY_INVERT 0x0002
|
||||||
#define SQLITE_CHANGESETAPPLY_IGNORENOOP 0x0004
|
#define SQLITE_CHANGESETAPPLY_IGNORENOOP 0x0004
|
||||||
#define SQLITE_CHANGESETAPPLY_FKNOACTION 0x0008
|
#define SQLITE_CHANGESETAPPLY_FKNOACTION 0x0008
|
||||||
|
#define SQLITE_CHANGESETAPPLY_NOUPDATELOOP 0x0010
|
||||||
|
|
||||||
/*
|
/*
|
||||||
** CAPI3REF: Constants Passed To The Conflict Handler
|
** CAPI3REF: Constants Passed To The Conflict Handler
|
||||||
|
|||||||
Reference in New Issue
Block a user