138115 lines
4.7 MiB
138115 lines
4.7 MiB
/******************************************************************************
|
||
** This file is an amalgamation of many separate C source files from SQLite
|
||
** version 3.7.16.1. By combining all the individual C code files into this
|
||
** single large file, the entire code can be compiled as a single translation
|
||
** unit. This allows many compilers to do optimizations that would not be
|
||
** possible if the files were compiled separately. Performance improvements
|
||
** of 5% or more are commonly seen when SQLite is compiled as a single
|
||
** translation unit.
|
||
**
|
||
** This file is all you need to compile SQLite. To use SQLite in other
|
||
** programs, you need this file and the "sqlite3.h" header file that defines
|
||
** the programming interface to the SQLite library. (If you do not have
|
||
** the "sqlite3.h" header file at hand, you will find a copy embedded within
|
||
** the text of this file. Search for "Begin file sqlite3.h" to find the start
|
||
** of the embedded sqlite3.h header file.) Additional code files may be needed
|
||
** if you want a wrapper to interface SQLite with your choice of programming
|
||
** language. The code for the "sqlite3" command-line shell is also in a
|
||
** separate file. This file contains only code for the core SQLite library.
|
||
*/
|
||
#define SQLITE_CORE 1
|
||
#define SQLITE_AMALGAMATION 1
|
||
#ifndef SQLITE_PRIVATE
|
||
# define SQLITE_PRIVATE static
|
||
#endif
|
||
#ifndef SQLITE_API
|
||
# define SQLITE_API
|
||
#endif
|
||
/************** Begin file sqliteInt.h ***************************************/
|
||
/*
|
||
** 2001 September 15
|
||
**
|
||
** The author disclaims copyright to this source code. In place of
|
||
** a legal notice, here is a blessing:
|
||
**
|
||
** May you do good and not evil.
|
||
** May you find forgiveness for yourself and forgive others.
|
||
** May you share freely, never taking more than you give.
|
||
**
|
||
*************************************************************************
|
||
** Internal interface definitions for SQLite.
|
||
**
|
||
*/
|
||
#ifndef _SQLITEINT_H_
|
||
#define _SQLITEINT_H_
|
||
|
||
/*
|
||
** These #defines should enable >2GB file support on POSIX if the
|
||
** underlying operating system supports it. If the OS lacks
|
||
** large file support, or if the OS is windows, these should be no-ops.
|
||
**
|
||
** Ticket #2739: The _LARGEFILE_SOURCE macro must appear before any
|
||
** system #includes. Hence, this block of code must be the very first
|
||
** code in all source files.
|
||
**
|
||
** Large file support can be disabled using the -DSQLITE_DISABLE_LFS switch
|
||
** on the compiler command line. This is necessary if you are compiling
|
||
** on a recent machine (ex: Red Hat 7.2) but you want your code to work
|
||
** on an older machine (ex: Red Hat 6.0). If you compile on Red Hat 7.2
|
||
** without this option, LFS is enable. But LFS does not exist in the kernel
|
||
** in Red Hat 6.0, so the code won't work. Hence, for maximum binary
|
||
** portability you should omit LFS.
|
||
**
|
||
** Similar is true for Mac OS X. LFS is only supported on Mac OS X 9 and later.
|
||
*/
|
||
#ifndef SQLITE_DISABLE_LFS
|
||
# define _LARGE_FILE 1
|
||
# ifndef _FILE_OFFSET_BITS
|
||
# define _FILE_OFFSET_BITS 64
|
||
# endif
|
||
# define _LARGEFILE_SOURCE 1
|
||
#endif
|
||
|
||
/*
|
||
** Include the configuration header output by 'configure' if we're using the
|
||
** autoconf-based build
|
||
*/
|
||
#ifdef _HAVE_SQLITE_CONFIG_H
|
||
#include "config.h"
|
||
#endif
|
||
|
||
/************** Include sqliteLimit.h in the middle of sqliteInt.h ***********/
|
||
/************** Begin file sqliteLimit.h *************************************/
|
||
/*
|
||
** 2007 May 7
|
||
**
|
||
** The author disclaims copyright to this source code. In place of
|
||
** a legal notice, here is a blessing:
|
||
**
|
||
** May you do good and not evil.
|
||
** May you find forgiveness for yourself and forgive others.
|
||
** May you share freely, never taking more than you give.
|
||
**
|
||
*************************************************************************
|
||
**
|
||
** This file defines various limits of what SQLite can process.
|
||
*/
|
||
|
||
/*
|
||
** The maximum length of a TEXT or BLOB in bytes. This also
|
||
** limits the size of a row in a table or index.
|
||
**
|
||
** The hard limit is the ability of a 32-bit signed integer
|
||
** to count the size: 2^31-1 or 2147483647.
|
||
*/
|
||
#ifndef SQLITE_MAX_LENGTH
|
||
# define SQLITE_MAX_LENGTH 1000000000
|
||
#endif
|
||
|
||
/*
|
||
** This is the maximum number of
|
||
**
|
||
** * Columns in a table
|
||
** * Columns in an index
|
||
** * Columns in a view
|
||
** * Terms in the SET clause of an UPDATE statement
|
||
** * Terms in the result set of a SELECT statement
|
||
** * Terms in the GROUP BY or ORDER BY clauses of a SELECT statement.
|
||
** * Terms in the VALUES clause of an INSERT statement
|
||
**
|
||
** The hard upper limit here is 32676. Most database people will
|
||
** tell you that in a well-normalized database, you usually should
|
||
** not have more than a dozen or so columns in any table. And if
|
||
** that is the case, there is no point in having more than a few
|
||
** dozen values in any of the other situations described above.
|
||
*/
|
||
#ifndef SQLITE_MAX_COLUMN
|
||
# define SQLITE_MAX_COLUMN 2000
|
||
#endif
|
||
|
||
/*
|
||
** The maximum length of a single SQL statement in bytes.
|
||
**
|
||
** It used to be the case that setting this value to zero would
|
||
** turn the limit off. That is no longer true. It is not possible
|
||
** to turn this limit off.
|
||
*/
|
||
#ifndef SQLITE_MAX_SQL_LENGTH
|
||
# define SQLITE_MAX_SQL_LENGTH 1000000000
|
||
#endif
|
||
|
||
/*
|
||
** The maximum depth of an expression tree. This is limited to
|
||
** some extent by SQLITE_MAX_SQL_LENGTH. But sometime you might
|
||
** want to place more severe limits on the complexity of an
|
||
** expression.
|
||
**
|
||
** A value of 0 used to mean that the limit was not enforced.
|
||
** But that is no longer true. The limit is now strictly enforced
|
||
** at all times.
|
||
*/
|
||
#ifndef SQLITE_MAX_EXPR_DEPTH
|
||
# define SQLITE_MAX_EXPR_DEPTH 1000
|
||
#endif
|
||
|
||
/*
|
||
** The maximum number of terms in a compound SELECT statement.
|
||
** The code generator for compound SELECT statements does one
|
||
** level of recursion for each term. A stack overflow can result
|
||
** if the number of terms is too large. In practice, most SQL
|
||
** never has more than 3 or 4 terms. Use a value of 0 to disable
|
||
** any limit on the number of terms in a compount SELECT.
|
||
*/
|
||
#ifndef SQLITE_MAX_COMPOUND_SELECT
|
||
# define SQLITE_MAX_COMPOUND_SELECT 500
|
||
#endif
|
||
|
||
/*
|
||
** The maximum number of opcodes in a VDBE program.
|
||
** Not currently enforced.
|
||
*/
|
||
#ifndef SQLITE_MAX_VDBE_OP
|
||
# define SQLITE_MAX_VDBE_OP 25000
|
||
#endif
|
||
|
||
/*
|
||
** The maximum number of arguments to an SQL function.
|
||
*/
|
||
#ifndef SQLITE_MAX_FUNCTION_ARG
|
||
# define SQLITE_MAX_FUNCTION_ARG 127
|
||
#endif
|
||
|
||
/*
|
||
** The maximum number of in-memory pages to use for the main database
|
||
** table and for temporary tables. The SQLITE_DEFAULT_CACHE_SIZE
|
||
*/
|
||
#ifndef SQLITE_DEFAULT_CACHE_SIZE
|
||
# define SQLITE_DEFAULT_CACHE_SIZE 2000
|
||
#endif
|
||
#ifndef SQLITE_DEFAULT_TEMP_CACHE_SIZE
|
||
# define SQLITE_DEFAULT_TEMP_CACHE_SIZE 500
|
||
#endif
|
||
|
||
/*
|
||
** The default number of frames to accumulate in the log file before
|
||
** checkpointing the database in WAL mode.
|
||
*/
|
||
#ifndef SQLITE_DEFAULT_WAL_AUTOCHECKPOINT
|
||
# define SQLITE_DEFAULT_WAL_AUTOCHECKPOINT 1000
|
||
#endif
|
||
|
||
/*
|
||
** The maximum number of attached databases. This must be between 0
|
||
** and 62. The upper bound on 62 is because a 64-bit integer bitmap
|
||
** is used internally to track attached databases.
|
||
*/
|
||
#ifndef SQLITE_MAX_ATTACHED
|
||
# define SQLITE_MAX_ATTACHED 10
|
||
#endif
|
||
|
||
|
||
/*
|
||
** The maximum value of a ?nnn wildcard that the parser will accept.
|
||
*/
|
||
#ifndef SQLITE_MAX_VARIABLE_NUMBER
|
||
# define SQLITE_MAX_VARIABLE_NUMBER 999
|
||
#endif
|
||
|
||
/* Maximum page size. The upper bound on this value is 65536. This a limit
|
||
** imposed by the use of 16-bit offsets within each page.
|
||
**
|
||
** Earlier versions of SQLite allowed the user to change this value at
|
||
** compile time. This is no longer permitted, on the grounds that it creates
|
||
** a library that is technically incompatible with an SQLite library
|
||
** compiled with a different limit. If a process operating on a database
|
||
** with a page-size of 65536 bytes crashes, then an instance of SQLite
|
||
** compiled with the default page-size limit will not be able to rollback
|
||
** the aborted transaction. This could lead to database corruption.
|
||
*/
|
||
#ifdef SQLITE_MAX_PAGE_SIZE
|
||
# undef SQLITE_MAX_PAGE_SIZE
|
||
#endif
|
||
#define SQLITE_MAX_PAGE_SIZE 65536
|
||
|
||
|
||
/*
|
||
** The default size of a database page.
|
||
*/
|
||
#ifndef SQLITE_DEFAULT_PAGE_SIZE
|
||
# define SQLITE_DEFAULT_PAGE_SIZE 1024
|
||
#endif
|
||
#if SQLITE_DEFAULT_PAGE_SIZE>SQLITE_MAX_PAGE_SIZE
|
||
# undef SQLITE_DEFAULT_PAGE_SIZE
|
||
# define SQLITE_DEFAULT_PAGE_SIZE SQLITE_MAX_PAGE_SIZE
|
||
#endif
|
||
|
||
/*
|
||
** Ordinarily, if no value is explicitly provided, SQLite creates databases
|
||
** with page size SQLITE_DEFAULT_PAGE_SIZE. However, based on certain
|
||
** device characteristics (sector-size and atomic write() support),
|
||
** SQLite may choose a larger value. This constant is the maximum value
|
||
** SQLite will choose on its own.
|
||
*/
|
||
#ifndef SQLITE_MAX_DEFAULT_PAGE_SIZE
|
||
# define SQLITE_MAX_DEFAULT_PAGE_SIZE 8192
|
||
#endif
|
||
#if SQLITE_MAX_DEFAULT_PAGE_SIZE>SQLITE_MAX_PAGE_SIZE
|
||
# undef SQLITE_MAX_DEFAULT_PAGE_SIZE
|
||
# define SQLITE_MAX_DEFAULT_PAGE_SIZE SQLITE_MAX_PAGE_SIZE
|
||
#endif
|
||
|
||
|
||
/*
|
||
** Maximum number of pages in one database file.
|
||
**
|
||
** This is really just the default value for the max_page_count pragma.
|
||
** This value can be lowered (or raised) at run-time using that the
|
||
** max_page_count macro.
|
||
*/
|
||
#ifndef SQLITE_MAX_PAGE_COUNT
|
||
# define SQLITE_MAX_PAGE_COUNT 1073741823
|
||
#endif
|
||
|
||
/*
|
||
** Maximum length (in bytes) of the pattern in a LIKE or GLOB
|
||
** operator.
|
||
*/
|
||
#ifndef SQLITE_MAX_LIKE_PATTERN_LENGTH
|
||
# define SQLITE_MAX_LIKE_PATTERN_LENGTH 50000
|
||
#endif
|
||
|
||
/*
|
||
** Maximum depth of recursion for triggers.
|
||
**
|
||
** A value of 1 means that a trigger program will not be able to itself
|
||
** fire any triggers. A value of 0 means that no trigger programs at all
|
||
** may be executed.
|
||
*/
|
||
#ifndef SQLITE_MAX_TRIGGER_DEPTH
|
||
# define SQLITE_MAX_TRIGGER_DEPTH 1000
|
||
#endif
|
||
|
||
/************** End of sqliteLimit.h *****************************************/
|
||
/************** Continuing where we left off in sqliteInt.h ******************/
|
||
|
||
/* Disable nuisance warnings on Borland compilers */
|
||
#if defined(__BORLANDC__)
|
||
#pragma warn -rch /* unreachable code */
|
||
#pragma warn -ccc /* Condition is always true or false */
|
||
#pragma warn -aus /* Assigned value is never used */
|
||
#pragma warn -csu /* Comparing signed and unsigned */
|
||
#pragma warn -spa /* Suspicious pointer arithmetic */
|
||
#endif
|
||
|
||
/* Needed for various definitions... */
|
||
#ifndef _GNU_SOURCE
|
||
# define _GNU_SOURCE
|
||
#endif
|
||
|
||
#if defined(__OpenBSD__) && !defined(_BSD_SOURCE)
|
||
# define _BSD_SOURCE
|
||
#endif
|
||
|
||
/*
|
||
** Include standard header files as necessary
|
||
*/
|
||
#ifdef HAVE_STDINT_H
|
||
#include <stdint.h>
|
||
#endif
|
||
#ifdef HAVE_INTTYPES_H
|
||
#include <inttypes.h>
|
||
#endif
|
||
|
||
/*
|
||
** The following macros are used to cast pointers to integers and
|
||
** integers to pointers. The way you do this varies from one compiler
|
||
** to the next, so we have developed the following set of #if statements
|
||
** to generate appropriate macros for a wide range of compilers.
|
||
**
|
||
** The correct "ANSI" way to do this is to use the intptr_t type.
|
||
** Unfortunately, that typedef is not available on all compilers, or
|
||
** if it is available, it requires an #include of specific headers
|
||
** that vary from one machine to the next.
|
||
**
|
||
** Ticket #3860: The llvm-gcc-4.2 compiler from Apple chokes on
|
||
** the ((void*)&((char*)0)[X]) construct. But MSVC chokes on ((void*)(X)).
|
||
** So we have to define the macros in different ways depending on the
|
||
** compiler.
|
||
*/
|
||
#if defined(__PTRDIFF_TYPE__) /* This case should work for GCC */
|
||
# define SQLITE_INT_TO_PTR(X) ((void*)(__PTRDIFF_TYPE__)(X))
|
||
# define SQLITE_PTR_TO_INT(X) ((int)(__PTRDIFF_TYPE__)(X))
|
||
#elif !defined(__GNUC__) /* Works for compilers other than LLVM */
|
||
# define SQLITE_INT_TO_PTR(X) ((void*)&((char*)0)[X])
|
||
# define SQLITE_PTR_TO_INT(X) ((int)(((char*)X)-(char*)0))
|
||
#elif defined(HAVE_STDINT_H) /* Use this case if we have ANSI headers */
|
||
# define SQLITE_INT_TO_PTR(X) ((void*)(intptr_t)(X))
|
||
# define SQLITE_PTR_TO_INT(X) ((int)(intptr_t)(X))
|
||
#else /* Generates a warning - but it always works */
|
||
# define SQLITE_INT_TO_PTR(X) ((void*)(X))
|
||
# define SQLITE_PTR_TO_INT(X) ((int)(X))
|
||
#endif
|
||
|
||
/*
|
||
** The SQLITE_THREADSAFE macro must be defined as 0, 1, or 2.
|
||
** 0 means mutexes are permanently disable and the library is never
|
||
** threadsafe. 1 means the library is serialized which is the highest
|
||
** level of threadsafety. 2 means the libary is multithreaded - multiple
|
||
** threads can use SQLite as long as no two threads try to use the same
|
||
** database connection at the same time.
|
||
**
|
||
** Older versions of SQLite used an optional THREADSAFE macro.
|
||
** We support that for legacy.
|
||
*/
|
||
#if !defined(SQLITE_THREADSAFE)
|
||
#if defined(THREADSAFE)
|
||
# define SQLITE_THREADSAFE THREADSAFE
|
||
#else
|
||
# define SQLITE_THREADSAFE 1 /* IMP: R-07272-22309 */
|
||
#endif
|
||
#endif
|
||
|
||
/*
|
||
** Powersafe overwrite is on by default. But can be turned off using
|
||
** the -DSQLITE_POWERSAFE_OVERWRITE=0 command-line option.
|
||
*/
|
||
#ifndef SQLITE_POWERSAFE_OVERWRITE
|
||
# define SQLITE_POWERSAFE_OVERWRITE 1
|
||
#endif
|
||
|
||
/*
|
||
** The SQLITE_DEFAULT_MEMSTATUS macro must be defined as either 0 or 1.
|
||
** It determines whether or not the features related to
|
||
** SQLITE_CONFIG_MEMSTATUS are available by default or not. This value can
|
||
** be overridden at runtime using the sqlite3_config() API.
|
||
*/
|
||
#if !defined(SQLITE_DEFAULT_MEMSTATUS)
|
||
# define SQLITE_DEFAULT_MEMSTATUS 1
|
||
#endif
|
||
|
||
/*
|
||
** Exactly one of the following macros must be defined in order to
|
||
** specify which memory allocation subsystem to use.
|
||
**
|
||
** SQLITE_SYSTEM_MALLOC // Use normal system malloc()
|
||
** SQLITE_WIN32_MALLOC // Use Win32 native heap API
|
||
** SQLITE_ZERO_MALLOC // Use a stub allocator that always fails
|
||
** SQLITE_MEMDEBUG // Debugging version of system malloc()
|
||
**
|
||
** On Windows, if the SQLITE_WIN32_MALLOC_VALIDATE macro is defined and the
|
||
** assert() macro is enabled, each call into the Win32 native heap subsystem
|
||
** will cause HeapValidate to be called. If heap validation should fail, an
|
||
** assertion will be triggered.
|
||
**
|
||
** (Historical note: There used to be several other options, but we've
|
||
** pared it down to just these three.)
|
||
**
|
||
** If none of the above are defined, then set SQLITE_SYSTEM_MALLOC as
|
||
** the default.
|
||
*/
|
||
#if defined(SQLITE_SYSTEM_MALLOC) \
|
||
+ defined(SQLITE_WIN32_MALLOC) \
|
||
+ defined(SQLITE_ZERO_MALLOC) \
|
||
+ defined(SQLITE_MEMDEBUG)>1
|
||
# error "Two or more of the following compile-time configuration options\
|
||
are defined but at most one is allowed:\
|
||
SQLITE_SYSTEM_MALLOC, SQLITE_WIN32_MALLOC, SQLITE_MEMDEBUG,\
|
||
SQLITE_ZERO_MALLOC"
|
||
#endif
|
||
#if defined(SQLITE_SYSTEM_MALLOC) \
|
||
+ defined(SQLITE_WIN32_MALLOC) \
|
||
+ defined(SQLITE_ZERO_MALLOC) \
|
||
+ defined(SQLITE_MEMDEBUG)==0
|
||
# define SQLITE_SYSTEM_MALLOC 1
|
||
#endif
|
||
|
||
/*
|
||
** If SQLITE_MALLOC_SOFT_LIMIT is not zero, then try to keep the
|
||
** sizes of memory allocations below this value where possible.
|
||
*/
|
||
#if !defined(SQLITE_MALLOC_SOFT_LIMIT)
|
||
# define SQLITE_MALLOC_SOFT_LIMIT 1024
|
||
#endif
|
||
|
||
/*
|
||
** We need to define _XOPEN_SOURCE as follows in order to enable
|
||
** recursive mutexes on most Unix systems. But Mac OS X is different.
|
||
** The _XOPEN_SOURCE define causes problems for Mac OS X we are told,
|
||
** so it is omitted there. See ticket #2673.
|
||
**
|
||
** Later we learn that _XOPEN_SOURCE is poorly or incorrectly
|
||
** implemented on some systems. So we avoid defining it at all
|
||
** if it is already defined or if it is unneeded because we are
|
||
** not doing a threadsafe build. Ticket #2681.
|
||
**
|
||
** See also ticket #2741.
|
||
*/
|
||
#if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) \
|
||
&& !defined(__APPLE__) && SQLITE_THREADSAFE
|
||
# define _XOPEN_SOURCE 500 /* Needed to enable pthread recursive mutexes */
|
||
#endif
|
||
|
||
/*
|
||
** The TCL headers are only needed when compiling the TCL bindings.
|
||
*/
|
||
#if defined(SQLITE_TCL) || defined(TCLSH)
|
||
# include <tcl.h>
|
||
#endif
|
||
|
||
/*
|
||
** NDEBUG and SQLITE_DEBUG are opposites. It should always be true that
|
||
** defined(NDEBUG)==!defined(SQLITE_DEBUG). If this is not currently true,
|
||
** make it true by defining or undefining NDEBUG.
|
||
**
|
||
** Setting NDEBUG makes the code smaller and run faster by disabling the
|
||
** number assert() statements in the code. So we want the default action
|
||
** to be for NDEBUG to be set and NDEBUG to be undefined only if SQLITE_DEBUG
|
||
** is set. Thus NDEBUG becomes an opt-in rather than an opt-out
|
||
** feature.
|
||
*/
|
||
#if !defined(NDEBUG) && !defined(SQLITE_DEBUG)
|
||
# define NDEBUG 1
|
||
#endif
|
||
#if defined(NDEBUG) && defined(SQLITE_DEBUG)
|
||
# undef NDEBUG
|
||
#endif
|
||
|
||
/*
|
||
** The testcase() macro is used to aid in coverage testing. When
|
||
** doing coverage testing, the condition inside the argument to
|
||
** testcase() must be evaluated both true and false in order to
|
||
** get full branch coverage. The testcase() macro is inserted
|
||
** to help ensure adequate test coverage in places where simple
|
||
** condition/decision coverage is inadequate. For example, testcase()
|
||
** can be used to make sure boundary values are tested. For
|
||
** bitmask tests, testcase() can be used to make sure each bit
|
||
** is significant and used at least once. On switch statements
|
||
** where multiple cases go to the same block of code, testcase()
|
||
** can insure that all cases are evaluated.
|
||
**
|
||
*/
|
||
#ifdef SQLITE_COVERAGE_TEST
|
||
SQLITE_PRIVATE void sqlite3Coverage(int);
|
||
# define testcase(X) if( X ){ sqlite3Coverage(__LINE__); }
|
||
#else
|
||
# define testcase(X)
|
||
#endif
|
||
|
||
/*
|
||
** The TESTONLY macro is used to enclose variable declarations or
|
||
** other bits of code that are needed to support the arguments
|
||
** within testcase() and assert() macros.
|
||
*/
|
||
#if !defined(NDEBUG) || defined(SQLITE_COVERAGE_TEST)
|
||
# define TESTONLY(X) X
|
||
#else
|
||
# define TESTONLY(X)
|
||
#endif
|
||
|
||
/*
|
||
** Sometimes we need a small amount of code such as a variable initialization
|
||
** to setup for a later assert() statement. We do not want this code to
|
||
** appear when assert() is disabled. The following macro is therefore
|
||
** used to contain that setup code. The "VVA" acronym stands for
|
||
** "Verification, Validation, and Accreditation". In other words, the
|
||
** code within VVA_ONLY() will only run during verification processes.
|
||
*/
|
||
#ifndef NDEBUG
|
||
# define VVA_ONLY(X) X
|
||
#else
|
||
# define VVA_ONLY(X)
|
||
#endif
|
||
|
||
/*
|
||
** The ALWAYS and NEVER macros surround boolean expressions which
|
||
** are intended to always be true or false, respectively. Such
|
||
** expressions could be omitted from the code completely. But they
|
||
** are included in a few cases in order to enhance the resilience
|
||
** of SQLite to unexpected behavior - to make the code "self-healing"
|
||
** or "ductile" rather than being "brittle" and crashing at the first
|
||
** hint of unplanned behavior.
|
||
**
|
||
** In other words, ALWAYS and NEVER are added for defensive code.
|
||
**
|
||
** When doing coverage testing ALWAYS and NEVER are hard-coded to
|
||
** be true and false so that the unreachable code then specify will
|
||
** not be counted as untested code.
|
||
*/
|
||
#if defined(SQLITE_COVERAGE_TEST)
|
||
# define ALWAYS(X) (1)
|
||
# define NEVER(X) (0)
|
||
#elif !defined(NDEBUG)
|
||
# define ALWAYS(X) ((X)?1:(assert(0),0))
|
||
# define NEVER(X) ((X)?(assert(0),1):0)
|
||
#else
|
||
# define ALWAYS(X) (X)
|
||
# define NEVER(X) (X)
|
||
#endif
|
||
|
||
/*
|
||
** Return true (non-zero) if the input is a integer that is too large
|
||
** to fit in 32-bits. This macro is used inside of various testcase()
|
||
** macros to verify that we have tested SQLite for large-file support.
|
||
*/
|
||
#define IS_BIG_INT(X) (((X)&~(i64)0xffffffff)!=0)
|
||
|
||
/*
|
||
** The macro unlikely() is a hint that surrounds a boolean
|
||
** expression that is usually false. Macro likely() surrounds
|
||
** a boolean expression that is usually true. GCC is able to
|
||
** use these hints to generate better code, sometimes.
|
||
*/
|
||
#if defined(__GNUC__) && 0
|
||
# define likely(X) __builtin_expect((X),1)
|
||
# define unlikely(X) __builtin_expect((X),0)
|
||
#else
|
||
# define likely(X) !!(X)
|
||
# define unlikely(X) !!(X)
|
||
#endif
|
||
|
||
/************** Include sqlite3.h in the middle of sqliteInt.h ***************/
|
||
/************** Begin file sqlite3.h *****************************************/
|
||
/*
|
||
** 2001 September 15
|
||
**
|
||
** The author disclaims copyright to this source code. In place of
|
||
** a legal notice, here is a blessing:
|
||
**
|
||
** May you do good and not evil.
|
||
** May you find forgiveness for yourself and forgive others.
|
||
** May you share freely, never taking more than you give.
|
||
**
|
||
*************************************************************************
|
||
** This header file defines the interface that the SQLite library
|
||
** presents to client programs. If a C-function, structure, datatype,
|
||
** or constant definition does not appear in this file, then it is
|
||
** not a published API of SQLite, is subject to change without
|
||
** notice, and should not be referenced by programs that use SQLite.
|
||
**
|
||
** Some of the definitions that are in this file are marked as
|
||
** "experimental". Experimental interfaces are normally new
|
||
** features recently added to SQLite. We do not anticipate changes
|
||
** to experimental interfaces but reserve the right to make minor changes
|
||
** if experience from use "in the wild" suggest such changes are prudent.
|
||
**
|
||
** The official C-language API documentation for SQLite is derived
|
||
** from comments in this file. This file is the authoritative source
|
||
** on how SQLite interfaces are suppose to operate.
|
||
**
|
||
** The name of this file under configuration management is "sqlite.h.in".
|
||
** The makefile makes some minor changes to this file (such as inserting
|
||
** the version number) and changes its name to "sqlite3.h" as
|
||
** part of the build process.
|
||
*/
|
||
#ifndef _SQLITE3_H_
|
||
#define _SQLITE3_H_
|
||
#include <stdarg.h> /* Needed for the definition of va_list */
|
||
|
||
/*
|
||
** Make sure we can call this stuff from C++.
|
||
*/
|
||
#if 0
|
||
extern "C" {
|
||
#endif
|
||
|
||
|
||
/*
|
||
** Add the ability to override 'extern'
|
||
*/
|
||
#ifndef SQLITE_EXTERN
|
||
# define SQLITE_EXTERN extern
|
||
#endif
|
||
|
||
#ifndef SQLITE_API
|
||
# define SQLITE_API
|
||
#endif
|
||
|
||
|
||
/*
|
||
** These no-op macros are used in front of interfaces to mark those
|
||
** interfaces as either deprecated or experimental. New applications
|
||
** should not use deprecated interfaces - they are support for backwards
|
||
** compatibility only. Application writers should be aware that
|
||
** experimental interfaces are subject to change in point releases.
|
||
**
|
||
** These macros used to resolve to various kinds of compiler magic that
|
||
** would generate warning messages when they were used. But that
|
||
** compiler magic ended up generating such a flurry of bug reports
|
||
** that we have taken it all out and gone back to using simple
|
||
** noop macros.
|
||
*/
|
||
#define SQLITE_DEPRECATED
|
||
#define SQLITE_EXPERIMENTAL
|
||
|
||
/*
|
||
** Ensure these symbols were not defined by some previous header file.
|
||
*/
|
||
#ifdef SQLITE_VERSION
|
||
# undef SQLITE_VERSION
|
||
#endif
|
||
#ifdef SQLITE_VERSION_NUMBER
|
||
# undef SQLITE_VERSION_NUMBER
|
||
#endif
|
||
|
||
/*
|
||
** CAPI3REF: Compile-Time Library Version Numbers
|
||
**
|
||
** ^(The [SQLITE_VERSION] C preprocessor macro in the sqlite3.h header
|
||
** evaluates to a string literal that is the SQLite version in the
|
||
** format "X.Y.Z" where X is the major version number (always 3 for
|
||
** SQLite3) and Y is the minor version number and Z is the release number.)^
|
||
** ^(The [SQLITE_VERSION_NUMBER] C preprocessor macro resolves to an integer
|
||
** with the value (X*1000000 + Y*1000 + Z) where X, Y, and Z are the same
|
||
** numbers used in [SQLITE_VERSION].)^
|
||
** The SQLITE_VERSION_NUMBER for any given release of SQLite will also
|
||
** be larger than the release from which it is derived. Either Y will
|
||
** be held constant and Z will be incremented or else Y will be incremented
|
||
** and Z will be reset to zero.
|
||
**
|
||
** Since version 3.6.18, SQLite source code has been stored in the
|
||
** <a href="http://www.fossil-scm.org/">Fossil configuration management
|
||
** system</a>. ^The SQLITE_SOURCE_ID macro evaluates to
|
||
** a string which identifies a particular check-in of SQLite
|
||
** within its configuration management system. ^The SQLITE_SOURCE_ID
|
||
** string contains the date and time of the check-in (UTC) and an SHA1
|
||
** hash of the entire source tree.
|
||
**
|
||
** See also: [sqlite3_libversion()],
|
||
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
|
||
** [sqlite_version()] and [sqlite_source_id()].
|
||
*/
|
||
#define SQLITE_VERSION "3.7.16.1"
|
||
#define SQLITE_VERSION_NUMBER 3007016
|
||
#define SQLITE_SOURCE_ID "2013-03-29 13:44:34 527231bc67285f01fb18d4451b28f61da3c4e39d"
|
||
|
||
/*
|
||
** 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
|
||
** but are associated with the library instead of the header file. ^(Cautious
|
||
** programmers might include assert() statements in their application to
|
||
** verify that values returned by these interfaces match the macros in
|
||
** the header, and thus insure that the application is
|
||
** compiled with matching library and header files.
|
||
**
|
||
** <blockquote><pre>
|
||
** assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );
|
||
** assert( strcmp(sqlite3_sourceid(),SQLITE_SOURCE_ID)==0 );
|
||
** assert( strcmp(sqlite3_libversion(),SQLITE_VERSION)==0 );
|
||
** </pre></blockquote>)^
|
||
**
|
||
** ^The sqlite3_version[] string constant contains the text of [SQLITE_VERSION]
|
||
** macro. ^The sqlite3_libversion() function returns a pointer to the
|
||
** to the sqlite3_version[] string constant. The sqlite3_libversion()
|
||
** function is provided for use in DLLs since DLL users usually do not have
|
||
** direct access to string constants within the DLL. ^The
|
||
** sqlite3_libversion_number() function returns an integer equal to
|
||
** [SQLITE_VERSION_NUMBER]. ^The sqlite3_sourceid() function returns
|
||
** a pointer to a string constant whose value is the same as the
|
||
** [SQLITE_SOURCE_ID] C preprocessor macro.
|
||
**
|
||
** See also: [sqlite_version()] and [sqlite_source_id()].
|
||
*/
|
||
SQLITE_API const char sqlite3_version[] = SQLITE_VERSION;
|
||
SQLITE_API const char *sqlite3_libversion(void);
|
||
SQLITE_API const char *sqlite3_sourceid(void);
|
||
SQLITE_API int sqlite3_libversion_number(void);
|
||
|
||
/*
|
||
** CAPI3REF: Run-Time Library Compilation Options Diagnostics
|
||
**
|
||
** ^The sqlite3_compileoption_used() function returns 0 or 1
|
||
** indicating whether the specified option was defined at
|
||
** compile time. ^The SQLITE_ prefix may be omitted from the
|
||
** option name passed to sqlite3_compileoption_used().
|
||
**
|
||
** ^The sqlite3_compileoption_get() function allows iterating
|
||
** over the list of options that were defined at compile time by
|
||
** returning the N-th compile time option string. ^If N is out of range,
|
||
** sqlite3_compileoption_get() returns a NULL pointer. ^The SQLITE_
|
||
** prefix is omitted from any strings returned by
|
||
** sqlite3_compileoption_get().
|
||
**
|
||
** ^Support for the diagnostic functions sqlite3_compileoption_used()
|
||
** and sqlite3_compileoption_get() may be omitted by specifying the
|
||
** [SQLITE_OMIT_COMPILEOPTION_DIAGS] option at compile time.
|
||
**
|
||
** See also: SQL functions [sqlite_compileoption_used()] and
|
||
** [sqlite_compileoption_get()] and the [compile_options pragma].
|
||
*/
|
||
#ifndef SQLITE_OMIT_COMPILEOPTION_DIAGS
|
||
SQLITE_API int sqlite3_compileoption_used(const char *zOptName);
|
||
SQLITE_API const char *sqlite3_compileoption_get(int N);
|
||
#endif
|
||
|
||
/*
|
||
** CAPI3REF: Test To See If The Library Is Threadsafe
|
||
**
|
||
** ^The sqlite3_threadsafe() function returns zero if and only if
|
||
** SQLite was compiled with mutexing code omitted due to the
|
||
** [SQLITE_THREADSAFE] compile-time option being set to 0.
|
||
**
|
||
** SQLite can be compiled with or without mutexes. When
|
||
** the [SQLITE_THREADSAFE] C preprocessor macro is 1 or 2, mutexes
|
||
** are enabled and SQLite is threadsafe. When the
|
||
** [SQLITE_THREADSAFE] macro is 0,
|
||
** the mutexes are omitted. Without the mutexes, it is not safe
|
||
** to use SQLite concurrently from more than one thread.
|
||
**
|
||
** Enabling mutexes incurs a measurable performance penalty.
|
||
** So if speed is of utmost importance, it makes sense to disable
|
||
** the mutexes. But for maximum safety, mutexes should be enabled.
|
||
** ^The default behavior is for mutexes to be enabled.
|
||
**
|
||
** This interface can be used by an application to make sure that the
|
||
** version of SQLite that it is linking against was compiled with
|
||
** the desired setting of the [SQLITE_THREADSAFE] macro.
|
||
**
|
||
** This interface only reports on the compile-time mutex setting
|
||
** of the [SQLITE_THREADSAFE] flag. If SQLite is compiled with
|
||
** SQLITE_THREADSAFE=1 or =2 then mutexes are enabled by default but
|
||
** can be fully or partially disabled using a call to [sqlite3_config()]
|
||
** with the verbs [SQLITE_CONFIG_SINGLETHREAD], [SQLITE_CONFIG_MULTITHREAD],
|
||
** or [SQLITE_CONFIG_MUTEX]. ^(The return value of the
|
||
** sqlite3_threadsafe() function shows only the compile-time setting of
|
||
** thread safety, not any run-time changes to that setting made by
|
||
** sqlite3_config(). In other words, the return value from sqlite3_threadsafe()
|
||
** is unchanged by calls to sqlite3_config().)^
|
||
**
|
||
** See the [threading mode] documentation for additional information.
|
||
*/
|
||
SQLITE_API int sqlite3_threadsafe(void);
|
||
|
||
/*
|
||
** CAPI3REF: Database Connection Handle
|
||
** KEYWORDS: {database connection} {database connections}
|
||
**
|
||
** Each open SQLite database is represented by a pointer to an instance of
|
||
** the opaque structure named "sqlite3". It is useful to think of an sqlite3
|
||
** pointer as an object. The [sqlite3_open()], [sqlite3_open16()], and
|
||
** [sqlite3_open_v2()] interfaces are its constructors, and [sqlite3_close()]
|
||
** and [sqlite3_close_v2()] are its destructors. There are many other
|
||
** interfaces (such as
|
||
** [sqlite3_prepare_v2()], [sqlite3_create_function()], and
|
||
** [sqlite3_busy_timeout()] to name but three) that are methods on an
|
||
** sqlite3 object.
|
||
*/
|
||
typedef struct sqlite3 sqlite3;
|
||
|
||
/*
|
||
** CAPI3REF: 64-Bit Integer Types
|
||
** KEYWORDS: sqlite_int64 sqlite_uint64
|
||
**
|
||
** Because there is no cross-platform way to specify 64-bit integer types
|
||
** SQLite includes typedefs for 64-bit signed and unsigned integers.
|
||
**
|
||
** The sqlite3_int64 and sqlite3_uint64 are the preferred type definitions.
|
||
** The sqlite_int64 and sqlite_uint64 types are supported for backwards
|
||
** compatibility only.
|
||
**
|
||
** ^The sqlite3_int64 and sqlite_int64 types can store integer values
|
||
** between -9223372036854775808 and +9223372036854775807 inclusive. ^The
|
||
** sqlite3_uint64 and sqlite_uint64 types can store integer values
|
||
** between 0 and +18446744073709551615 inclusive.
|
||
*/
|
||
#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;
|
||
|
||
/*
|
||
** If compiling for a processor that lacks floating point support,
|
||
** substitute integer for floating-point.
|
||
*/
|
||
#ifdef SQLITE_OMIT_FLOATING_POINT
|
||
# define double sqlite3_int64
|
||
#endif
|
||
|
||
/*
|
||
** CAPI3REF: Closing A Database Connection
|
||
**
|
||
** ^The sqlite3_close() and sqlite3_close_v2() routines are destructors
|
||
** for the [sqlite3] object.
|
||
** ^Calls to sqlite3_close() and sqlite3_close_v2() return SQLITE_OK if
|
||
** the [sqlite3] object is successfully destroyed and all associated
|
||
** resources are deallocated.
|
||
**
|
||
** ^If the database connection is associated with unfinalized prepared
|
||
** statements or unfinished sqlite3_backup objects then sqlite3_close()
|
||
** will leave the database connection open and return [SQLITE_BUSY].
|
||
** ^If sqlite3_close_v2() is called with unfinalized prepared statements
|
||
** and unfinished sqlite3_backups, then the database connection becomes
|
||
** an unusable "zombie" which will automatically be deallocated when the
|
||
** last prepared statement is finalized or the last sqlite3_backup is
|
||
** finished. The sqlite3_close_v2() interface is intended for use with
|
||
** host languages that are garbage collected, and where the order in which
|
||
** destructors are called is arbitrary.
|
||
**
|
||
** Applications should [sqlite3_finalize | finalize] all [prepared statements],
|
||
** [sqlite3_blob_close | close] all [BLOB handles], and
|
||
** [sqlite3_backup_finish | finish] all [sqlite3_backup] objects associated
|
||
** with the [sqlite3] object prior to attempting to close the object. ^If
|
||
** sqlite3_close_v2() is called on a [database connection] that still has
|
||
** outstanding [prepared statements], [BLOB handles], and/or
|
||
** [sqlite3_backup] objects then it returns SQLITE_OK but the deallocation
|
||
** of resources is deferred until all [prepared statements], [BLOB handles],
|
||
** and [sqlite3_backup] objects are also destroyed.
|
||
**
|
||
** ^If an [sqlite3] object is destroyed while a transaction is open,
|
||
** the transaction is automatically rolled back.
|
||
**
|
||
** The C parameter to [sqlite3_close(C)] and [sqlite3_close_v2(C)]
|
||
** must be either a NULL
|
||
** pointer or an [sqlite3] object pointer obtained
|
||
** from [sqlite3_open()], [sqlite3_open16()], or
|
||
** [sqlite3_open_v2()], and not previously closed.
|
||
** ^Calling sqlite3_close() or sqlite3_close_v2() with a NULL pointer
|
||
** argument is a harmless no-op.
|
||
*/
|
||
SQLITE_API int sqlite3_close(sqlite3*);
|
||
SQLITE_API int sqlite3_close_v2(sqlite3*);
|
||
|
||
/*
|
||
** The type for a callback function.
|
||
** This is legacy and deprecated. It is included for historical
|
||
** compatibility and is not documented.
|
||
*/
|
||
typedef int (*sqlite3_callback)(void*,int,char**, char**);
|
||
|
||
/*
|
||
** CAPI3REF: One-Step Query Execution Interface
|
||
**
|
||
** The sqlite3_exec() interface is a convenience wrapper around
|
||
** [sqlite3_prepare_v2()], [sqlite3_step()], and [sqlite3_finalize()],
|
||
** that allows an application to run multiple statements of SQL
|
||
** without having to use a lot of C code.
|
||
**
|
||
** ^The sqlite3_exec() interface runs zero or more UTF-8 encoded,
|
||
** semicolon-separate SQL statements passed into its 2nd argument,
|
||
** in the context of the [database connection] passed in as its 1st
|
||
** argument. ^If the callback function of the 3rd argument to
|
||
** sqlite3_exec() is not NULL, then it is invoked for each result row
|
||
** coming out of the evaluated SQL statements. ^The 4th argument to
|
||
** sqlite3_exec() is relayed through to the 1st argument of each
|
||
** callback invocation. ^If the callback pointer to sqlite3_exec()
|
||
** is NULL, then no callback is ever invoked and result rows are
|
||
** ignored.
|
||
**
|
||
** ^If an error occurs while evaluating the SQL statements passed into
|
||
** sqlite3_exec(), then execution of the current statement stops and
|
||
** subsequent statements are skipped. ^If the 5th parameter to sqlite3_exec()
|
||
** is not NULL then any error message is written into memory obtained
|
||
** from [sqlite3_malloc()] and passed back through the 5th parameter.
|
||
** To avoid memory leaks, the application should invoke [sqlite3_free()]
|
||
** on error message strings returned through the 5th parameter of
|
||
** of sqlite3_exec() after the error message string is no longer needed.
|
||
** ^If the 5th parameter to sqlite3_exec() is not NULL and no errors
|
||
** occur, then sqlite3_exec() sets the pointer in its 5th parameter to
|
||
** NULL before returning.
|
||
**
|
||
** ^If an sqlite3_exec() callback returns non-zero, the sqlite3_exec()
|
||
** routine returns SQLITE_ABORT without invoking the callback again and
|
||
** without running any subsequent SQL statements.
|
||
**
|
||
** ^The 2nd argument to the sqlite3_exec() callback function is the
|
||
** number of columns in the result. ^The 3rd argument to the sqlite3_exec()
|
||
** callback is an array of pointers to strings obtained as if from
|
||
** [sqlite3_column_text()], one for each column. ^If an element of a
|
||
** result row is NULL then the corresponding string pointer for the
|
||
** sqlite3_exec() callback is a NULL pointer. ^The 4th argument to the
|
||
** sqlite3_exec() callback is an array of pointers to strings where each
|
||
** entry represents the name of corresponding result column as obtained
|
||
** from [sqlite3_column_name()].
|
||
**
|
||
** ^If the 2nd parameter to sqlite3_exec() is a NULL pointer, a pointer
|
||
** to an empty string, or a pointer that contains only whitespace and/or
|
||
** SQL comments, then no SQL statements are evaluated and the database
|
||
** is not changed.
|
||
**
|
||
** Restrictions:
|
||
**
|
||
** <ul>
|
||
** <li> The application must insure that the 1st parameter to sqlite3_exec()
|
||
** is a valid and open [database connection].
|
||
** <li> The application must not close [database connection] specified by
|
||
** the 1st parameter to sqlite3_exec() while sqlite3_exec() is running.
|
||
** <li> The application must not modify the SQL statement text passed into
|
||
** the 2nd parameter of sqlite3_exec() while sqlite3_exec() is running.
|
||
** </ul>
|
||
*/
|
||
SQLITE_API 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 */
|
||
);
|
||
|
||
/*
|
||
** CAPI3REF: Result Codes
|
||
** KEYWORDS: SQLITE_OK {error code} {error codes}
|
||
** KEYWORDS: {result code} {result codes}
|
||
**
|
||
** Many SQLite functions return an integer result code from the set shown
|
||
** here in order to indicate success or failure.
|
||
**
|
||
** New error codes may be added in future versions of SQLite.
|
||
**
|
||
** See also: [SQLITE_IOERR_READ | extended result codes],
|
||
** [sqlite3_vtab_on_conflict()] [SQLITE_ROLLBACK | result codes].
|
||
*/
|
||
#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 /* Unknown opcode in sqlite3_file_control() */
|
||
#define SQLITE_FULL 13 /* Insertion failed because database is full */
|
||
#define SQLITE_CANTOPEN 14 /* Unable to open the database file */
|
||
#define SQLITE_PROTOCOL 15 /* 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 */
|
||
|
||
/*
|
||
** CAPI3REF: Extended Result Codes
|
||
** KEYWORDS: {extended error code} {extended error codes}
|
||
** KEYWORDS: {extended result code} {extended result codes}
|
||
**
|
||
** In its default configuration, SQLite API routines return one of 26 integer
|
||
** [SQLITE_OK | result codes]. However, experience has shown that many of
|
||
** these result codes are too coarse-grained. They do not provide as
|
||
** much information about problems as programmers might like. In an effort to
|
||
** address this, newer versions of SQLite (version 3.3.8 and later) include
|
||
** support for additional result codes that provide more detailed information
|
||
** about errors. The extended result codes are enabled or disabled
|
||
** on a per database connection basis using the
|
||
** [sqlite3_extended_result_codes()] API.
|
||
**
|
||
** Some of the available extended result codes are listed here.
|
||
** One may expect the number of extended result codes will be expand
|
||
** over time. Software that uses extended result codes should expect
|
||
** to see new result codes in future releases of SQLite.
|
||
**
|
||
** The SQLITE_OK result code will never be extended. It will always
|
||
** be exactly zero.
|
||
*/
|
||
#define SQLITE_IOERR_READ (SQLITE_IOERR | (1<<8))
|
||
#define SQLITE_IOERR_SHORT_READ (SQLITE_IOERR | (2<<8))
|
||
#define SQLITE_IOERR_WRITE (SQLITE_IOERR | (3<<8))
|
||
#define SQLITE_IOERR_FSYNC (SQLITE_IOERR | (4<<8))
|
||
#define SQLITE_IOERR_DIR_FSYNC (SQLITE_IOERR | (5<<8))
|
||
#define SQLITE_IOERR_TRUNCATE (SQLITE_IOERR | (6<<8))
|
||
#define SQLITE_IOERR_FSTAT (SQLITE_IOERR | (7<<8))
|
||
#define SQLITE_IOERR_UNLOCK (SQLITE_IOERR | (8<<8))
|
||
#define SQLITE_IOERR_RDLOCK (SQLITE_IOERR | (9<<8))
|
||
#define SQLITE_IOERR_DELETE (SQLITE_IOERR | (10<<8))
|
||
#define SQLITE_IOERR_BLOCKED (SQLITE_IOERR | (11<<8))
|
||
#define SQLITE_IOERR_NOMEM (SQLITE_IOERR | (12<<8))
|
||
#define SQLITE_IOERR_ACCESS (SQLITE_IOERR | (13<<8))
|
||
#define SQLITE_IOERR_CHECKRESERVEDLOCK (SQLITE_IOERR | (14<<8))
|
||
#define SQLITE_IOERR_LOCK (SQLITE_IOERR | (15<<8))
|
||
#define SQLITE_IOERR_CLOSE (SQLITE_IOERR | (16<<8))
|
||
#define SQLITE_IOERR_DIR_CLOSE (SQLITE_IOERR | (17<<8))
|
||
#define SQLITE_IOERR_SHMOPEN (SQLITE_IOERR | (18<<8))
|
||
#define SQLITE_IOERR_SHMSIZE (SQLITE_IOERR | (19<<8))
|
||
#define SQLITE_IOERR_SHMLOCK (SQLITE_IOERR | (20<<8))
|
||
#define SQLITE_IOERR_SHMMAP (SQLITE_IOERR | (21<<8))
|
||
#define SQLITE_IOERR_SEEK (SQLITE_IOERR | (22<<8))
|
||
#define SQLITE_IOERR_DELETE_NOENT (SQLITE_IOERR | (23<<8))
|
||
#define SQLITE_LOCKED_SHAREDCACHE (SQLITE_LOCKED | (1<<8))
|
||
#define SQLITE_BUSY_RECOVERY (SQLITE_BUSY | (1<<8))
|
||
#define SQLITE_CANTOPEN_NOTEMPDIR (SQLITE_CANTOPEN | (1<<8))
|
||
#define SQLITE_CANTOPEN_ISDIR (SQLITE_CANTOPEN | (2<<8))
|
||
#define SQLITE_CANTOPEN_FULLPATH (SQLITE_CANTOPEN | (3<<8))
|
||
#define SQLITE_CORRUPT_VTAB (SQLITE_CORRUPT | (1<<8))
|
||
#define SQLITE_READONLY_RECOVERY (SQLITE_READONLY | (1<<8))
|
||
#define SQLITE_READONLY_CANTLOCK (SQLITE_READONLY | (2<<8))
|
||
#define SQLITE_READONLY_ROLLBACK (SQLITE_READONLY | (3<<8))
|
||
#define SQLITE_ABORT_ROLLBACK (SQLITE_ABORT | (2<<8))
|
||
#define SQLITE_CONSTRAINT_CHECK (SQLITE_CONSTRAINT | (1<<8))
|
||
#define SQLITE_CONSTRAINT_COMMITHOOK (SQLITE_CONSTRAINT | (2<<8))
|
||
#define SQLITE_CONSTRAINT_FOREIGNKEY (SQLITE_CONSTRAINT | (3<<8))
|
||
#define SQLITE_CONSTRAINT_FUNCTION (SQLITE_CONSTRAINT | (4<<8))
|
||
#define SQLITE_CONSTRAINT_NOTNULL (SQLITE_CONSTRAINT | (5<<8))
|
||
#define SQLITE_CONSTRAINT_PRIMARYKEY (SQLITE_CONSTRAINT | (6<<8))
|
||
#define SQLITE_CONSTRAINT_TRIGGER (SQLITE_CONSTRAINT | (7<<8))
|
||
#define SQLITE_CONSTRAINT_UNIQUE (SQLITE_CONSTRAINT | (8<<8))
|
||
#define SQLITE_CONSTRAINT_VTAB (SQLITE_CONSTRAINT | (9<<8))
|
||
|
||
/*
|
||
** CAPI3REF: Flags For File Open Operations
|
||
**
|
||
** These bit values are intended for use in the
|
||
** 3rd parameter to the [sqlite3_open_v2()] interface and
|
||
** in the 4th parameter to the [sqlite3_vfs.xOpen] method.
|
||
*/
|
||
#define SQLITE_OPEN_READONLY 0x00000001 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_READWRITE 0x00000002 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_CREATE 0x00000004 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_DELETEONCLOSE 0x00000008 /* VFS only */
|
||
#define SQLITE_OPEN_EXCLUSIVE 0x00000010 /* VFS only */
|
||
#define SQLITE_OPEN_AUTOPROXY 0x00000020 /* VFS only */
|
||
#define SQLITE_OPEN_URI 0x00000040 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_MEMORY 0x00000080 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_MAIN_DB 0x00000100 /* VFS only */
|
||
#define SQLITE_OPEN_TEMP_DB 0x00000200 /* VFS only */
|
||
#define SQLITE_OPEN_TRANSIENT_DB 0x00000400 /* VFS only */
|
||
#define SQLITE_OPEN_MAIN_JOURNAL 0x00000800 /* VFS only */
|
||
#define SQLITE_OPEN_TEMP_JOURNAL 0x00001000 /* VFS only */
|
||
#define SQLITE_OPEN_SUBJOURNAL 0x00002000 /* VFS only */
|
||
#define SQLITE_OPEN_MASTER_JOURNAL 0x00004000 /* VFS only */
|
||
#define SQLITE_OPEN_NOMUTEX 0x00008000 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_FULLMUTEX 0x00010000 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_SHAREDCACHE 0x00020000 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_PRIVATECACHE 0x00040000 /* Ok for sqlite3_open_v2() */
|
||
#define SQLITE_OPEN_WAL 0x00080000 /* VFS only */
|
||
|
||
/* Reserved: 0x00F00000 */
|
||
|
||
/*
|
||
** CAPI3REF: Device Characteristics
|
||
**
|
||
** The xDeviceCharacteristics method of the [sqlite3_io_methods]
|
||
** object returns an integer which is a vector of these
|
||
** bit values expressing I/O characteristics of the mass storage
|
||
** device that holds the file that the [sqlite3_io_methods]
|
||
** refers to.
|
||
**
|
||
** The SQLITE_IOCAP_ATOMIC property means that all writes of
|
||
** any size are atomic. The SQLITE_IOCAP_ATOMICnnn values
|
||
** mean that writes of blocks that are nnn bytes in size and
|
||
** are aligned to an address which is an integer multiple of
|
||
** nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means
|
||
** that when data is appended to a file, the data is appended
|
||
** first then the size of the file is extended, never the other
|
||
** way around. The SQLITE_IOCAP_SEQUENTIAL property means that
|
||
** information is written to disk in the same order as calls
|
||
** to xWrite(). The SQLITE_IOCAP_POWERSAFE_OVERWRITE property means that
|
||
** after reboot following a crash or power loss, the only bytes in a
|
||
** file that were written at the application level might have changed
|
||
** and that adjacent bytes, even bytes within the same sector are
|
||
** guaranteed to be unchanged.
|
||
*/
|
||
#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
|
||
#define SQLITE_IOCAP_UNDELETABLE_WHEN_OPEN 0x00000800
|
||
#define SQLITE_IOCAP_POWERSAFE_OVERWRITE 0x00001000
|
||
|
||
/*
|
||
** CAPI3REF: File Locking Levels
|
||
**
|
||
** SQLite uses one of these integer values as the second
|
||
** argument to calls it makes to the xLock() and xUnlock() methods
|
||
** of an [sqlite3_io_methods] object.
|
||
*/
|
||
#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
|
||
|
||
/*
|
||
** CAPI3REF: Synchronization Type Flags
|
||
**
|
||
** When SQLite invokes the xSync() method of an
|
||
** [sqlite3_io_methods] object it uses a combination of
|
||
** these integer values as the second argument.
|
||
**
|
||
** When the SQLITE_SYNC_DATAONLY flag is used, it means that the
|
||
** sync operation only needs to flush data to mass storage. Inode
|
||
** information need not be flushed. If the lower four bits of the flag
|
||
** equal SQLITE_SYNC_NORMAL, that means to use normal fsync() semantics.
|
||
** If the lower four bits equal SQLITE_SYNC_FULL, that means
|
||
** to use Mac OS X style fullsync instead of fsync().
|
||
**
|
||
** Do not confuse the SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL flags
|
||
** with the [PRAGMA synchronous]=NORMAL and [PRAGMA synchronous]=FULL
|
||
** settings. The [synchronous pragma] determines when calls to the
|
||
** xSync VFS method occur and applies uniformly across all platforms.
|
||
** The SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL flags determine how
|
||
** energetic or rigorous or forceful the sync operations are and
|
||
** only make a difference on Mac OSX for the default SQLite code.
|
||
** (Third-party VFS implementations might also make the distinction
|
||
** between SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL, but among the
|
||
** operating systems natively supported by SQLite, only Mac OSX
|
||
** cares about the difference.)
|
||
*/
|
||
#define SQLITE_SYNC_NORMAL 0x00002
|
||
#define SQLITE_SYNC_FULL 0x00003
|
||
#define SQLITE_SYNC_DATAONLY 0x00010
|
||
|
||
/*
|
||
** CAPI3REF: OS Interface Open File Handle
|
||
**
|
||
** An [sqlite3_file] object represents an open file in the
|
||
** [sqlite3_vfs | OS interface layer]. Individual OS interface
|
||
** implementations will
|
||
** want to subclass this object by appending additional fields
|
||
** for their own use. The pMethods entry is a pointer to an
|
||
** [sqlite3_io_methods] object that defines methods for performing
|
||
** I/O operations on the open file.
|
||
*/
|
||
typedef struct sqlite3_file sqlite3_file;
|
||
struct sqlite3_file {
|
||
const struct sqlite3_io_methods *pMethods; /* Methods for an open file */
|
||
};
|
||
|
||
/*
|
||
** CAPI3REF: OS Interface File Virtual Methods Object
|
||
**
|
||
** Every file opened by the [sqlite3_vfs.xOpen] method populates an
|
||
** [sqlite3_file] object (or, more commonly, a subclass of the
|
||
** [sqlite3_file] object) with a pointer to an instance of this object.
|
||
** This object defines the methods used to perform various operations
|
||
** against the open file represented by the [sqlite3_file] object.
|
||
**
|
||
** If the [sqlite3_vfs.xOpen] method sets the sqlite3_file.pMethods element
|
||
** to a non-NULL pointer, then the sqlite3_io_methods.xClose method
|
||
** may be invoked even if the [sqlite3_vfs.xOpen] reported that it failed. The
|
||
** only way to prevent a call to xClose following a failed [sqlite3_vfs.xOpen]
|
||
** is for the [sqlite3_vfs.xOpen] to set the sqlite3_file.pMethods element
|
||
** to NULL.
|
||
**
|
||
** The flags argument to xSync may be one of [SQLITE_SYNC_NORMAL] or
|
||
** [SQLITE_SYNC_FULL]. The first choice is the normal fsync().
|
||
** The second choice is a Mac OS X style fullsync. The [SQLITE_SYNC_DATAONLY]
|
||
** flag may be ORed in to indicate that only the data of the file
|
||
** and not its inode needs to be synced.
|
||
**
|
||
** The integer values to xLock() and xUnlock() are one of
|
||
** <ul>
|
||
** <li> [SQLITE_LOCK_NONE],
|
||
** <li> [SQLITE_LOCK_SHARED],
|
||
** <li> [SQLITE_LOCK_RESERVED],
|
||
** <li> [SQLITE_LOCK_PENDING], or
|
||
** <li> [SQLITE_LOCK_EXCLUSIVE].
|
||
** </ul>
|
||
** xLock() increases the lock. xUnlock() decreases the lock.
|
||
** The xCheckReservedLock() method checks whether any database connection,
|
||
** either in this process or in some other process, is holding a RESERVED,
|
||
** PENDING, or EXCLUSIVE lock on the file. It returns true
|
||
** if such a lock exists and false otherwise.
|
||
**
|
||
** The xFileControl() method is a generic interface that allows custom
|
||
** VFS implementations to directly control an open file using the
|
||
** [sqlite3_file_control()] interface. The second "op" argument is an
|
||
** integer opcode. The third argument is a generic pointer intended to
|
||
** point to a structure that may contain arguments or space in which to
|
||
** write return values. Potential uses for xFileControl() might be
|
||
** functions to enable blocking locks with timeouts, to change the
|
||
** locking strategy (for example to use dot-file locks), to inquire
|
||
** about the status of a lock, or to break stale locks. The SQLite
|
||
** core reserves all opcodes less than 100 for its own use.
|
||
** A [SQLITE_FCNTL_LOCKSTATE | list of opcodes] less than 100 is available.
|
||
** Applications that define a custom xFileControl method should use opcodes
|
||
** greater than 100 to avoid conflicts. VFS implementations should
|
||
** return [SQLITE_NOTFOUND] for file control opcodes that they do not
|
||
** recognize.
|
||
**
|
||
** The xSectorSize() method returns the sector size of the
|
||
** device that underlies the file. The sector size is the
|
||
** minimum write that can be performed without disturbing
|
||
** other bytes in the file. The xDeviceCharacteristics()
|
||
** method returns a bit vector describing behaviors of the
|
||
** underlying device:
|
||
**
|
||
** <ul>
|
||
** <li> [SQLITE_IOCAP_ATOMIC]
|
||
** <li> [SQLITE_IOCAP_ATOMIC512]
|
||
** <li> [SQLITE_IOCAP_ATOMIC1K]
|
||
** <li> [SQLITE_IOCAP_ATOMIC2K]
|
||
** <li> [SQLITE_IOCAP_ATOMIC4K]
|
||
** <li> [SQLITE_IOCAP_ATOMIC8K]
|
||
** <li> [SQLITE_IOCAP_ATOMIC16K]
|
||
** <li> [SQLITE_IOCAP_ATOMIC32K]
|
||
** <li> [SQLITE_IOCAP_ATOMIC64K]
|
||
** <li> [SQLITE_IOCAP_SAFE_APPEND]
|
||
** <li> [SQLITE_IOCAP_SEQUENTIAL]
|
||
** </ul>
|
||
**
|
||
** The SQLITE_IOCAP_ATOMIC property means that all writes of
|
||
** any size are atomic. The SQLITE_IOCAP_ATOMICnnn values
|
||
** mean that writes of blocks that are nnn bytes in size and
|
||
** are aligned to an address which is an integer multiple of
|
||
** nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means
|
||
** that when data is appended to a file, the data is appended
|
||
** first then the size of the file is extended, never the other
|
||
** way around. The SQLITE_IOCAP_SEQUENTIAL property means that
|
||
** information is written to disk in the same order as calls
|
||
** to xWrite().
|
||
**
|
||
** If xRead() returns SQLITE_IOERR_SHORT_READ it must also fill
|
||
** in the unread portions of the buffer with zeros. A VFS that
|
||
** fails to zero-fill short reads might seem to work. However,
|
||
** failure to zero-fill short reads will eventually lead to
|
||
** database corruption.
|
||
*/
|
||
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*);
|
||
/* Methods above are valid for version 1 */
|
||
int (*xShmMap)(sqlite3_file*, int iPg, int pgsz, int, void volatile**);
|
||
int (*xShmLock)(sqlite3_file*, int offset, int n, int flags);
|
||
void (*xShmBarrier)(sqlite3_file*);
|
||
int (*xShmUnmap)(sqlite3_file*, int deleteFlag);
|
||
/* Methods above are valid for version 2 */
|
||
/* Additional methods may be added in future releases */
|
||
};
|
||
|
||
/*
|
||
** CAPI3REF: Standard File Control Opcodes
|
||
**
|
||
** These integer constants are opcodes for the xFileControl method
|
||
** of the [sqlite3_io_methods] object and for the [sqlite3_file_control()]
|
||
** interface.
|
||
**
|
||
** The [SQLITE_FCNTL_LOCKSTATE] opcode is used for debugging. This
|
||
** opcode causes the xFileControl method to write the current state of
|
||
** the lock (one of [SQLITE_LOCK_NONE], [SQLITE_LOCK_SHARED],
|
||
** [SQLITE_LOCK_RESERVED], [SQLITE_LOCK_PENDING], or [SQLITE_LOCK_EXCLUSIVE])
|
||
** into an integer that the pArg argument points to. This capability
|
||
** is used during testing and only needs to be supported when SQLITE_TEST
|
||
** is defined.
|
||
** <ul>
|
||
** <li>[[SQLITE_FCNTL_SIZE_HINT]]
|
||
** The [SQLITE_FCNTL_SIZE_HINT] opcode is used by SQLite to give the VFS
|
||
** layer a hint of how large the database file will grow to be during the
|
||
** current transaction. This hint is not guaranteed to be accurate but it
|
||
** is often close. The underlying VFS might choose to preallocate database
|
||
** file space based on this hint in order to help writes to the database
|
||
** file run faster.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_CHUNK_SIZE]]
|
||
** The [SQLITE_FCNTL_CHUNK_SIZE] opcode is used to request that the VFS
|
||
** extends and truncates the database file in chunks of a size specified
|
||
** by the user. The fourth argument to [sqlite3_file_control()] should
|
||
** point to an integer (type int) containing the new chunk-size to use
|
||
** for the nominated database. Allocating database file space in large
|
||
** chunks (say 1MB at a time), may reduce file-system fragmentation and
|
||
** improve performance on some systems.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_FILE_POINTER]]
|
||
** The [SQLITE_FCNTL_FILE_POINTER] opcode is used to obtain a pointer
|
||
** to the [sqlite3_file] object associated with a particular database
|
||
** connection. See the [sqlite3_file_control()] documentation for
|
||
** additional information.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_SYNC_OMITTED]]
|
||
** ^(The [SQLITE_FCNTL_SYNC_OMITTED] opcode is generated internally by
|
||
** SQLite and sent to all VFSes in place of a call to the xSync method
|
||
** when the database connection has [PRAGMA synchronous] set to OFF.)^
|
||
** Some specialized VFSes need this signal in order to operate correctly
|
||
** when [PRAGMA synchronous | PRAGMA synchronous=OFF] is set, but most
|
||
** VFSes do not need this signal and should silently ignore this opcode.
|
||
** Applications should not call [sqlite3_file_control()] with this
|
||
** opcode as doing so may disrupt the operation of the specialized VFSes
|
||
** that do require it.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_WIN32_AV_RETRY]]
|
||
** ^The [SQLITE_FCNTL_WIN32_AV_RETRY] opcode is used to configure automatic
|
||
** retry counts and intervals for certain disk I/O operations for the
|
||
** windows [VFS] in order to provide robustness in the presence of
|
||
** anti-virus programs. By default, the windows VFS will retry file read,
|
||
** file write, and file delete operations up to 10 times, with a delay
|
||
** of 25 milliseconds before the first retry and with the delay increasing
|
||
** by an additional 25 milliseconds with each subsequent retry. This
|
||
** opcode allows these two values (10 retries and 25 milliseconds of delay)
|
||
** to be adjusted. The values are changed for all database connections
|
||
** within the same process. The argument is a pointer to an array of two
|
||
** integers where the first integer i the new retry count and the second
|
||
** integer is the delay. If either integer is negative, then the setting
|
||
** is not changed but instead the prior value of that setting is written
|
||
** into the array entry, allowing the current retry settings to be
|
||
** interrogated. The zDbName parameter is ignored.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_PERSIST_WAL]]
|
||
** ^The [SQLITE_FCNTL_PERSIST_WAL] opcode is used to set or query the
|
||
** persistent [WAL | Write Ahead Log] setting. By default, the auxiliary
|
||
** write ahead log and shared memory files used for transaction control
|
||
** are automatically deleted when the latest connection to the database
|
||
** closes. Setting persistent WAL mode causes those files to persist after
|
||
** close. Persisting the files is useful when other processes that do not
|
||
** have write permission on the directory containing the database file want
|
||
** to read the database file, as the WAL and shared memory files must exist
|
||
** in order for the database to be readable. The fourth parameter to
|
||
** [sqlite3_file_control()] for this opcode should be a pointer to an integer.
|
||
** That integer is 0 to disable persistent WAL mode or 1 to enable persistent
|
||
** WAL mode. If the integer is -1, then it is overwritten with the current
|
||
** WAL persistence setting.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_POWERSAFE_OVERWRITE]]
|
||
** ^The [SQLITE_FCNTL_POWERSAFE_OVERWRITE] opcode is used to set or query the
|
||
** persistent "powersafe-overwrite" or "PSOW" setting. The PSOW setting
|
||
** determines the [SQLITE_IOCAP_POWERSAFE_OVERWRITE] bit of the
|
||
** xDeviceCharacteristics methods. The fourth parameter to
|
||
** [sqlite3_file_control()] for this opcode should be a pointer to an integer.
|
||
** That integer is 0 to disable zero-damage mode or 1 to enable zero-damage
|
||
** mode. If the integer is -1, then it is overwritten with the current
|
||
** zero-damage mode setting.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_OVERWRITE]]
|
||
** ^The [SQLITE_FCNTL_OVERWRITE] opcode is invoked by SQLite after opening
|
||
** a write transaction to indicate that, unless it is rolled back for some
|
||
** reason, the entire database file will be overwritten by the current
|
||
** transaction. This is used by VACUUM operations.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_VFSNAME]]
|
||
** ^The [SQLITE_FCNTL_VFSNAME] opcode can be used to obtain the names of
|
||
** all [VFSes] in the VFS stack. The names are of all VFS shims and the
|
||
** final bottom-level VFS are written into memory obtained from
|
||
** [sqlite3_malloc()] and the result is stored in the char* variable
|
||
** that the fourth parameter of [sqlite3_file_control()] points to.
|
||
** The caller is responsible for freeing the memory when done. As with
|
||
** all file-control actions, there is no guarantee that this will actually
|
||
** do anything. Callers should initialize the char* variable to a NULL
|
||
** pointer in case this file-control is not implemented. This file-control
|
||
** is intended for diagnostic use only.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_PRAGMA]]
|
||
** ^Whenever a [PRAGMA] statement is parsed, an [SQLITE_FCNTL_PRAGMA]
|
||
** file control is sent to the open [sqlite3_file] object corresponding
|
||
** to the database file to which the pragma statement refers. ^The argument
|
||
** to the [SQLITE_FCNTL_PRAGMA] file control is an array of
|
||
** pointers to strings (char**) in which the second element of the array
|
||
** is the name of the pragma and the third element is the argument to the
|
||
** pragma or NULL if the pragma has no argument. ^The handler for an
|
||
** [SQLITE_FCNTL_PRAGMA] file control can optionally make the first element
|
||
** of the char** argument point to a string obtained from [sqlite3_mprintf()]
|
||
** or the equivalent and that string will become the result of the pragma or
|
||
** the error message if the pragma fails. ^If the
|
||
** [SQLITE_FCNTL_PRAGMA] file control returns [SQLITE_NOTFOUND], then normal
|
||
** [PRAGMA] processing continues. ^If the [SQLITE_FCNTL_PRAGMA]
|
||
** file control returns [SQLITE_OK], then the parser assumes that the
|
||
** VFS has handled the PRAGMA itself and the parser generates a no-op
|
||
** prepared statement. ^If the [SQLITE_FCNTL_PRAGMA] file control returns
|
||
** any result code other than [SQLITE_OK] or [SQLITE_NOTFOUND], that means
|
||
** that the VFS encountered an error while handling the [PRAGMA] and the
|
||
** compilation of the PRAGMA fails with an error. ^The [SQLITE_FCNTL_PRAGMA]
|
||
** file control occurs at the beginning of pragma statement analysis and so
|
||
** it is able to override built-in [PRAGMA] statements.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_BUSYHANDLER]]
|
||
** ^This file-control may be invoked by SQLite on the database file handle
|
||
** shortly after it is opened in order to provide a custom VFS with access
|
||
** to the connections busy-handler callback. The argument is of type (void **)
|
||
** - an array of two (void *) values. The first (void *) actually points
|
||
** to a function of type (int (*)(void *)). In order to invoke the connections
|
||
** busy-handler, this function should be invoked with the second (void *) in
|
||
** the array as the only argument. If it returns non-zero, then the operation
|
||
** should be retried. If it returns zero, the custom VFS should abandon the
|
||
** current operation.
|
||
**
|
||
** <li>[[SQLITE_FCNTL_TEMPFILENAME]]
|
||
** ^Application can invoke this file-control to have SQLite generate a
|
||
** temporary filename using the same algorithm that is followed to generate
|
||
** temporary filenames for TEMP tables and other internal uses. The
|
||
** argument should be a char** which will be filled with the filename
|
||
** written into memory obtained from [sqlite3_malloc()]. The caller should
|
||
** invoke [sqlite3_free()] on the result to avoid a memory leak.
|
||
**
|
||
** </ul>
|
||
*/
|
||
#define SQLITE_FCNTL_LOCKSTATE 1
|
||
#define SQLITE_GET_LOCKPROXYFILE 2
|
||
#define SQLITE_SET_LOCKPROXYFILE 3
|
||
#define SQLITE_LAST_ERRNO 4
|
||
#define SQLITE_FCNTL_SIZE_HINT 5
|
||
#define SQLITE_FCNTL_CHUNK_SIZE 6
|
||
#define SQLITE_FCNTL_FILE_POINTER 7
|
||
#define SQLITE_FCNTL_SYNC_OMITTED 8
|
||
#define SQLITE_FCNTL_WIN32_AV_RETRY 9
|
||
#define SQLITE_FCNTL_PERSIST_WAL 10
|
||
#define SQLITE_FCNTL_OVERWRITE 11
|
||
#define SQLITE_FCNTL_VFSNAME 12
|
||
#define SQLITE_FCNTL_POWERSAFE_OVERWRITE 13
|
||
#define SQLITE_FCNTL_PRAGMA 14
|
||
#define SQLITE_FCNTL_BUSYHANDLER 15
|
||
#define SQLITE_FCNTL_TEMPFILENAME 16
|
||
|
||
/*
|
||
** CAPI3REF: Mutex Handle
|
||
**
|
||
** The mutex module within SQLite defines [sqlite3_mutex] to be an
|
||
** abstract type for a mutex object. The SQLite core never looks
|
||
** at the internal representation of an [sqlite3_mutex]. It only
|
||
** deals with pointers to the [sqlite3_mutex] object.
|
||
**
|
||
** Mutexes are created using [sqlite3_mutex_alloc()].
|
||
*/
|
||
typedef struct sqlite3_mutex sqlite3_mutex;
|
||
|
||
/*
|
||
** CAPI3REF: OS Interface Object
|
||
**
|
||
** An instance of the sqlite3_vfs object defines the interface between
|
||
** the SQLite core and the underlying operating system. The "vfs"
|
||
** in the name of the object stands for "virtual file system". See
|
||
** the [VFS | VFS documentation] for further information.
|
||
**
|
||
** The value of the iVersion field is initially 1 but may be larger in
|
||
** future versions of SQLite. Additional fields may be appended to this
|
||
** object when the iVersion value is increased. Note that the structure
|
||
** of the sqlite3_vfs object changes in the transaction between
|
||
** SQLite version 3.5.9 and 3.6.0 and yet the iVersion field was not
|
||
** modified.
|
||
**
|
||
** The szOsFile field is the size of the subclassed [sqlite3_file]
|
||
** structure used by this VFS. mxPathname is the maximum length of
|
||
** a pathname in this VFS.
|
||
**
|
||
** Registered sqlite3_vfs objects are kept on a linked list formed by
|
||
** the pNext pointer. The [sqlite3_vfs_register()]
|
||
** and [sqlite3_vfs_unregister()] interfaces manage this list
|
||
** in a thread-safe way. The [sqlite3_vfs_find()] interface
|
||
** searches the list. Neither the application code nor the VFS
|
||
** implementation should use the pNext pointer.
|
||
**
|
||
** The pNext field is the only field in the sqlite3_vfs
|
||
** structure that SQLite will ever modify. SQLite will only access
|
||
** or modify this field while holding a particular static mutex.
|
||
** The application should never modify anything within the sqlite3_vfs
|
||
** object once the object has been registered.
|
||
**
|
||
** The zName field holds the name of the VFS module. The name must
|
||
** be unique across all VFS modules.
|
||
**
|
||
** [[sqlite3_vfs.xOpen]]
|
||
** ^SQLite guarantees that the zFilename parameter to xOpen
|
||
** is either a NULL pointer or string obtained
|
||
** from xFullPathname() with an optional suffix added.
|
||
** ^If a suffix is added to the zFilename parameter, it will
|
||
** consist of a single "-" character followed by no more than
|
||
** 11 alphanumeric and/or "-" characters.
|
||
** ^SQLite further guarantees that
|
||
** the string will be valid and unchanged until xClose() is
|
||
** called. Because of the previous sentence,
|
||
** the [sqlite3_file] can safely store a pointer to the
|
||
** filename if it needs to remember the filename for some reason.
|
||
** If the zFilename parameter to xOpen is a NULL pointer then xOpen
|
||
** must invent its own temporary name for the file. ^Whenever the
|
||
** xFilename parameter is NULL it will also be the case that the
|
||
** flags parameter will include [SQLITE_OPEN_DELETEONCLOSE].
|
||
**
|
||
** The flags argument to xOpen() includes all bits set in
|
||
** the flags argument to [sqlite3_open_v2()]. Or if [sqlite3_open()]
|
||
** or [sqlite3_open16()] is used, then flags includes at least
|
||
** [SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE].
|
||
** If xOpen() opens a file read-only then it sets *pOutFlags to
|
||
** include [SQLITE_OPEN_READONLY]. Other bits in *pOutFlags may be set.
|
||
**
|
||
** ^(SQLite will also add one of the following flags to the xOpen()
|
||
** call, depending on the object being opened:
|
||
**
|
||
** <ul>
|
||
** <li> [SQLITE_OPEN_MAIN_DB]
|
||
** <li> [SQLITE_OPEN_MAIN_JOURNAL]
|
||
** <li> [SQLITE_OPEN_TEMP_DB]
|
||
** <li> [SQLITE_OPEN_TEMP_JOURNAL]
|
||
** <li> [SQLITE_OPEN_TRANSIENT_DB]
|
||
** <li> [SQLITE_OPEN_SUBJOURNAL]
|
||
** <li> [SQLITE_OPEN_MASTER_JOURNAL]
|
||
** <li> [SQLITE_OPEN_WAL]
|
||
** </ul>)^
|
||
**
|
||
** The file I/O implementation can use the object type flags to
|
||
** change the way it deals with files. For example, an application
|
||
** that does not care about crash recovery or rollback might make
|
||
** the open of a journal file a no-op. Writes to this journal would
|
||
** also be no-ops, and any attempt to read the journal would return
|
||
** SQLITE_IOERR. Or the implementation might recognize that a database
|
||
** file will be doing page-aligned sector reads and writes in a random
|
||
** order and set up its I/O subsystem accordingly.
|
||
**
|
||
** SQLite might also add one of the following flags to the xOpen method:
|
||
**
|
||
** <ul>
|
||
** <li> [SQLITE_OPEN_DELETEONCLOSE]
|
||
** <li> [SQLITE_OPEN_EXCLUSIVE]
|
||
** </ul>
|
||
**
|
||
** The [SQLITE_OPEN_DELETEONCLOSE] flag means the file should be
|
||
** deleted when it is closed. ^The [SQLITE_OPEN_DELETEONCLOSE]
|
||
** will be set for TEMP databases and their journals, transient
|
||
** databases, and subjournals.
|
||
**
|
||
** ^The [SQLITE_OPEN_EXCLUSIVE] flag is always used in conjunction
|
||
** with the [SQLITE_OPEN_CREATE] flag, which are both directly
|
||
** analogous to the O_EXCL and O_CREAT flags of the POSIX open()
|
||
** API. The SQLITE_OPEN_EXCLUSIVE flag, when paired with the
|
||
** SQLITE_OPEN_CREATE, is used to indicate that file should always
|
||
** be created, and that it is an error if it already exists.
|
||
** It is <i>not</i> used to indicate the file should be opened
|
||
** for exclusive access.
|
||
**
|
||
** ^At least szOsFile bytes of memory are allocated by SQLite
|
||
** to hold the [sqlite3_file] structure passed as the third
|
||
** argument to xOpen. The xOpen method does not have to
|
||
** allocate the structure; it should just fill it in. Note that
|
||
** the xOpen method must set the sqlite3_file.pMethods to either
|
||
** a valid [sqlite3_io_methods] object or to NULL. xOpen must do
|
||
** this even if the open fails. SQLite expects that the sqlite3_file.pMethods
|
||
** element will be valid after xOpen returns regardless of the success
|
||
** or failure of the xOpen call.
|
||
**
|
||
** [[sqlite3_vfs.xAccess]]
|
||
** ^The flags argument to xAccess() may be [SQLITE_ACCESS_EXISTS]
|
||
** to test for the existence of a file, or [SQLITE_ACCESS_READWRITE] to
|
||
** test whether a file is readable and writable, or [SQLITE_ACCESS_READ]
|
||
** to test whether a file is at least readable. The file can be a
|
||
** directory.
|
||
**
|
||
** ^SQLite will always allocate at least mxPathname+1 bytes for the
|
||
** output buffer xFullPathname. The exact size of the output buffer
|
||
** is also passed as a parameter to both methods. If the output buffer
|
||
** is not large enough, [SQLITE_CANTOPEN] should be returned. Since this is
|
||
** handled as a fatal error by SQLite, vfs implementations should endeavor
|
||
** to prevent this by setting mxPathname to a sufficiently large value.
|
||
**
|
||
** The xRandomness(), xSleep(), xCurrentTime(), and xCurrentTimeInt64()
|
||
** interfaces are not strictly a part of the filesystem, but they are
|
||
** included in the VFS structure for completeness.
|
||
** The xRandomness() function attempts to return nBytes bytes
|
||
** of good-quality randomness into zOut. The return value is
|
||
** the actual number of bytes of randomness obtained.
|
||
** The xSleep() method causes the calling thread to sleep for at
|
||
** least the number of microseconds given. ^The xCurrentTime()
|
||
** method returns a Julian Day Number for the current date and time as
|
||
** a floating point value.
|
||
** ^The xCurrentTimeInt64() method returns, as an integer, the Julian
|
||
** Day Number multiplied by 86400000 (the number of milliseconds in
|
||
** a 24-hour day).
|
||
** ^SQLite will use the xCurrentTimeInt64() method to get the current
|
||
** date and time if that method is available (if iVersion is 2 or
|
||
** greater and the function pointer is not NULL) and will fall back
|
||
** to xCurrentTime() if xCurrentTimeInt64() is unavailable.
|
||
**
|
||
** ^The xSetSystemCall(), xGetSystemCall(), and xNestSystemCall() interfaces
|
||
** are not used by the SQLite core. These optional interfaces are provided
|
||
** by some VFSes to facilitate testing of the VFS code. By overriding
|
||
** system calls with functions under its control, a test program can
|
||
** simulate faults and error conditions that would otherwise be difficult
|
||
** or impossible to induce. The set of system calls that can be overridden
|
||
** varies from one VFS to another, and from one version of the same VFS to the
|
||
** next. Applications that use these interfaces must be prepared for any
|
||
** or all of these interfaces to be NULL or for their behavior to change
|
||
** from one release to the next. Applications must not attempt to access
|
||
** any of these methods if the iVersion of the VFS is less than 3.
|
||
*/
|
||
typedef struct sqlite3_vfs sqlite3_vfs;
|
||
typedef void (*sqlite3_syscall_ptr)(void);
|
||
struct sqlite3_vfs {
|
||
int iVersion; /* Structure version number (currently 3) */
|
||
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 *);
|
||
/*
|
||
** The methods above are in version 1 of the sqlite_vfs object
|
||
** definition. Those that follow are added in version 2 or later
|
||
*/
|
||
int (*xCurrentTimeInt64)(sqlite3_vfs*, sqlite3_int64*);
|
||
/*
|
||
** The methods above are in versions 1 and 2 of the sqlite_vfs object.
|
||
** Those below are for version 3 and greater.
|
||
*/
|
||
int (*xSetSystemCall)(sqlite3_vfs*, const char *zName, sqlite3_syscall_ptr);
|
||
sqlite3_syscall_ptr (*xGetSystemCall)(sqlite3_vfs*, const char *zName);
|
||
const char *(*xNextSystemCall)(sqlite3_vfs*, const char *zName);
|
||
/*
|
||
** The methods above are in versions 1 through 3 of the sqlite_vfs object.
|
||
** New fields may be appended in figure versions. The iVersion
|
||
** value will increment whenever this happens.
|
||
*/
|
||
};
|
||
|
||
/*
|
||
** CAPI3REF: Flags for the xAccess VFS method
|
||
**
|
||
** These integer constants can be used as the third parameter to
|
||
** the xAccess method of an [sqlite3_vfs] object. They determine
|
||
** what kind of permissions the xAccess method is looking for.
|
||
** With SQLITE_ACCESS_EXISTS, the xAccess method
|
||
** simply checks whether the file exists.
|
||
** With SQLITE_ACCESS_READWRITE, the xAccess method
|
||
** checks whether the named directory is both readable and writable
|
||
** (in other words, if files can be added, removed, and renamed within
|
||
** the directory).
|
||
** The SQLITE_ACCESS_READWRITE constant is currently used only by the
|
||
** [temp_store_directory pragma], though this could change in a future
|
||
** release of SQLite.
|
||
** With SQLITE_ACCESS_READ, the xAccess method
|
||
** checks whether the file is readable. The SQLITE_ACCESS_READ constant is
|
||
** currently unused, though it might be used in a future release of
|
||
** SQLite.
|
||
*/
|
||
#define SQLITE_ACCESS_EXISTS 0
|
||
#define SQLITE_ACCESS_READWRITE 1 /* Used by PRAGMA temp_store_directory */
|
||
#define SQLITE_ACCESS_READ 2 /* Unused */
|
||
|
||
/*
|
||
** CAPI3REF: Flags for the xShmLock VFS method
|
||
**
|
||
** These integer constants define the various locking operations
|
||
** allowed by the xShmLock method of [sqlite3_io_methods]. The
|
||
** following are the only legal combinations of flags to the
|
||
** xShmLock method:
|
||
**
|
||
** <ul>
|
||
** <li> SQLITE_SHM_LOCK | SQLITE_SHM_SHARED
|
||
** <li> SQLITE_SHM_LOCK | SQLITE_SHM_EXCLUSIVE
|
||
** <li> SQLITE_SHM_UNLOCK | SQLITE_SHM_SHARED
|
||
** <li> SQLITE_SHM_UNLOCK | SQLITE_SHM_EXCLUSIVE
|
||
** </ul>
|
||
**
|
||
** When unlocking, the same SHARED or EXCLUSIVE flag must be supplied as
|
||
** was given no the corresponding lock.
|
||
**
|
||
** The xShmLock method can transition between unlocked and SHARED or
|
||
** between unlocked and EXCLUSIVE. It cannot transition between SHARED
|
||
** and EXCLUSIVE.
|
||
*/
|
||
#define SQLITE_SHM_UNLOCK 1
|
||
#define SQLITE_SHM_LOCK 2
|
||
#define SQLITE_SHM_SHARED 4
|
||
#define SQLITE_SHM_EXCLUSIVE 8
|
||
|
||
/*
|
||
** CAPI3REF: Maximum xShmLock index
|
||
**
|
||
** The xShmLock method on [sqlite3_io_methods] may use values
|
||
** between 0 and this upper bound as its "offset" argument.
|
||
** The SQLite core will never attempt to acquire or release a
|
||
** lock outside of this range
|
||
*/
|
||
#define SQLITE_SHM_NLOCK 8
|
||
|
||
|
||
/*
|
||
** CAPI3REF: Initialize The SQLite Library
|
||
**
|
||
** ^The sqlite3_initialize() routine initializes the
|
||
** SQLite library. ^The sqlite3_shutdown() routine
|
||
** deallocates any resources that were allocated by sqlite3_initialize().
|
||
** These routines are designed to aid in process initialization and
|
||
** shutdown on embedded systems. Workstation applications using
|
||
** SQLite normally do not need to invoke either of these routines.
|
||
**
|
||
** A call to sqlite3_initialize() is an "effective" call if it is
|
||
** the first time sqlite3_initialize() is invoked during the lifetime of
|
||
** the process, or if it is the first time sqlite3_initialize() is invoked
|
||
** following a call to sqlite3_shutdown(). ^(Only an effective call
|
||
** of sqlite3_initialize() does any initialization. All other calls
|
||
** are harmless no-ops.)^
|
||
**
|
||
** A call to sqlite3_shutdown() is an "effective" call if it is the first
|
||
** call to sqlite3_shutdown() since the last sqlite3_initialize(). ^(Only
|
||
** an effective call to sqlite3_shutdown() does any deinitialization.
|
||
** All other valid calls to sqlite3_shutdown() are harmless no-ops.)^
|
||
**
|
||
** The sqlite3_initialize() interface is threadsafe, but sqlite3_shutdown()
|
||
** is not. The sqlite3_shutdown() interface must only be called from a
|
||
** single thread. All open [database connections] must be closed and all
|
||
** other SQLite resources must be deallocated prior to invoking
|
||
** sqlite3_shutdown().
|
||
**
|
||
** Among other things, ^sqlite3_initialize() will invoke
|
||
** sqlite3_os_init(). Similarly, ^sqlite3_shutdown()
|
||
** will invoke sqlite3_os_end().
|
||
**
|
||
** ^The sqlite3_initialize() routine returns [SQLITE_OK] on success.
|
||
** ^If for some reason, sqlite3_initialize() is unable to initialize
|
||
** the library (perhaps it is unable to allocate a needed resource such
|
||
** as a mutex) it returns an [error code] other than [SQLITE_OK].
|
||
**
|
||
** ^The sqlite3_initialize() routine is called internally by many other
|
||
** SQLite interfaces so that an application usually does not need to
|
||
** invoke sqlite3_initialize() directly. For example, [sqlite3_open()]
|
||
** calls sqlite3_initialize() so the SQLite library will be automatically
|
||
** initialized when [sqlite3_open()] is called if it has not be initialized
|
||
** already. ^However, if SQLite is compiled with the [SQLITE_OMIT_AUTOINIT]
|
||
** compile-time option, then the automatic calls to sqlite3_initialize()
|
||
** are omitted and the application must call sqlite3_initialize() directly
|
||
** prior to using any other SQLite interface. For maximum portability,
|
||
** it is recommended that applications always invoke sqlite3_initialize()
|
||
** directly prior to using any other SQLite interface. Future releases
|
||
** of SQLite may require this. In other words, the behavior exhibited
|
||
** when SQLite is compiled with [SQLITE_OMIT_AUTOINIT] might become the
|
||
** default behavior in some future release of SQLite.
|
||
**
|
||
** The sqlite3_os_init() routine does operating-system specific
|
||
** initialization of the SQLite library. The sqlite3_os_end()
|
||
** routine undoes the effect of sqlite3_os_init(). Typical tasks
|
||
** performed by these routines include allocation or deallocation
|
||
** of static resources, initialization of global variables,
|
||
** setting up a default [sqlite3_vfs] module, or setting up
|
||
** a default configuration using [sqlite3_config()].
|
||
**
|
||
** The application should never invoke either sqlite3_os_init()
|
||
** or sqlite3_os_end() directly. The application should only invoke
|
||
** sqlite3_initialize() and sqlite3_shutdown(). The sqlite3_os_init()
|
||
** interface is called automatically by sqlite3_initialize() and
|
||
** sqlite3_os_end() is called by sqlite3_shutdown(). Appropriate
|
||
** implementations for sqlite3_os_init() and sqlite3_os_end()
|
||
** are built into SQLite when it is compiled for Unix, Windows, or OS/2.
|
||
** When [custom builds | built for other platforms]
|
||
** (using the [SQLITE_OS_OTHER=1] compile-time
|
||
** option) the application must supply a suitable implementation for
|
||
** sqlite3_os_init() and sqlite3_os_end(). An application-supplied
|
||
** implementation of sqlite3_os_init() or sqlite3_os_end()
|
||
** must return [SQLITE_OK] on success and some other [error code] upon
|
||
** failure.
|
||
*/
|
||
SQLITE_API int sqlite3_initialize(void);
|
||
SQLITE_API int sqlite3_shutdown(void);
|
||
SQLITE_API int sqlite3_os_init(void);
|
||
SQLITE_API int sqlite3_os_end(void);
|
||
|
||
/*
|
||
** CAPI3REF: Configuring The SQLite Library
|
||
**
|
||
** The sqlite3_config() interface is used to make global configuration
|
||
** changes to SQLite in order to tune SQLite to the specific needs of
|
||
** the application. The default configuration is recommended for most
|
||
** applications and so this routine is usually not necessary. It is
|
||
** provided to support rare applications with unusual needs.
|
||
**
|
||
** The sqlite3_config() interface is not threadsafe. The application
|
||
** must insure that no other SQLite interfaces are invoked by other
|
||
** threads while sqlite3_config() is running. Furthermore, sqlite3_config()
|
||
** may only be invoked prior to library initialization using
|
||
** [sqlite3_initialize()] or after shutdown by [sqlite3_shutdown()].
|
||
** ^If sqlite3_config() is called after [sqlite3_initialize()] and before
|
||
** [sqlite3_shutdown()] then it will return SQLITE_MISUSE.
|
||
** Note, however, that ^sqlite3_config() can be called as part of the
|
||
** implementation of an application-defined [sqlite3_os_init()].
|
||
**
|
||
** The first argument to sqlite3_config() is an integer
|
||
** [configuration option] that determines
|
||
** what property of SQLite is to be configured. Subsequent arguments
|
||
** vary depending on the [configuration option]
|
||
** in the first argument.
|
||
**
|
||
** ^When a configuration option is set, sqlite3_config() returns [SQLITE_OK].
|
||
** ^If the option is unknown or SQLite is unable to set the option
|
||
** then this routine returns a non-zero [error code].
|
||
*/
|
||
SQLITE_API int sqlite3_config(int, ...);
|
||
|
||
/*
|
||
** CAPI3REF: Configure database connections
|
||
**
|
||
** The sqlite3_db_config() interface is used to make configuration
|
||
** changes to a [database connection]. The interface is similar to
|
||
** [sqlite3_config()] except that the changes apply to a single
|
||
** [database connection] (specified in the first argument).
|
||
**
|
||
** The second argument to sqlite3_db_config(D,V,...) is the
|
||
** [SQLITE_DBCONFIG_LOOKASIDE | configuration verb] - an integer code
|
||
** that indicates what aspect of the [database connection] is being configured.
|
||
** Subsequent arguments vary depending on the configuration verb.
|
||
**
|
||
** ^Calls to sqlite3_db_config() return SQLITE_OK if and only if
|
||
** the call is considered successful.
|
||
*/
|
||
SQLITE_API int sqlite3_db_config(sqlite3*, int op, ...);
|
||
|
||
/*
|
||
** CAPI3REF: Memory Allocation Routines
|
||
**
|
||
** An instance of this object defines the interface between SQLite
|
||
** and low-level memory allocation routines.
|
||
**
|
||
** This object is used in only one place in the SQLite interface.
|
||
** A pointer to an instance of this object is the argument to
|
||
** [sqlite3_config()] when the configuration option is
|
||
** [SQLITE_CONFIG_MALLOC] or [SQLITE_CONFIG_GETMALLOC].
|
||
** By creating an instance of this object
|
||
** and passing it to [sqlite3_config]([SQLITE_CONFIG_MALLOC])
|
||
** during configuration, an application can specify an alternative
|
||
** memory allocation subsystem for SQLite to use for all of its
|
||
** dynamic memory needs.
|
||
**
|
||
** Note that SQLite comes with several [built-in memory allocators]
|
||
** that are perfectly adequate for the overwhelming majority of applications
|
||
** and that this object is only useful to a tiny minority of applications
|
||
** with specialized memory allocation requirements. This object is
|
||
** also used during testing of SQLite in order to specify an alternative
|
||
** memory allocator that simulates memory out-of-memory conditions in
|
||
** order to verify that SQLite recovers gracefully from such
|
||
** conditions.
|
||
**
|
||
** The xMalloc, xRealloc, and xFree methods must work like the
|
||
** malloc(), realloc() and free() functions from the standard C library.
|
||
** ^SQLite guarantees that the second argument to
|
||
** xRealloc is always a value returned by a prior call to xRoundup.
|
||
**
|
||
** xSize should return the allocated size of a memory allocation
|
||
** previously obtained from xMalloc or xRealloc. The allocated size
|
||
** is always at least as big as the requested size but may be larger.
|
||
**
|
||
** The xRoundup method returns what would be the allocated size of
|
||
** a memory allocation given a particular requested size. Most memory
|
||
** allocators round up memory allocations at least to the next multiple
|
||
** of 8. Some allocators round up to a larger multiple or to a power of 2.
|
||
** Every memory allocation request coming in through [sqlite3_malloc()]
|
||
** or [sqlite3_realloc()] first calls xRoundup. If xRoundup returns 0,
|
||
** that causes the corresponding memory allocation to fail.
|
||
**
|
||
** The xInit method initializes the memory allocator. (For example,
|
||
** it might allocate any require mutexes or initialize internal data
|
||
** structures. The xShutdown method is invoked (indirectly) by
|
||
** [sqlite3_shutdown()] and should deallocate any resources acquired
|
||
** by xInit. The pAppData pointer is used as the only parameter to
|
||
** xInit and xShutdown.
|
||
**
|
||
** SQLite holds the [SQLITE_MUTEX_STATIC_MASTER] mutex when it invokes
|
||
** the xInit method, so the xInit method need not be threadsafe. The
|
||
** xShutdown method is only called from [sqlite3_shutdown()] so it does
|
||
** not need to be threadsafe either. For all other methods, SQLite
|
||
** holds the [SQLITE_MUTEX_STATIC_MEM] mutex as long as the
|
||
** [SQLITE_CONFIG_MEMSTATUS] configuration option is turned on (which
|
||
** it is by default) and so the methods are automatically serialized.
|
||
** However, if [SQLITE_CONFIG_MEMSTATUS] is disabled, then the other
|
||
** methods must be threadsafe or else make their own arrangements for
|
||
** serialization.
|
||
**
|
||
** SQLite will never invoke xInit() more than once without an intervening
|
||
** call to xShutdown().
|
||
*/
|
||
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() */
|
||
};
|
||
|
||
/*
|
||
** CAPI3REF: Configuration Options
|
||
** KEYWORDS: {configuration option}
|
||
**
|
||
** These constants are the available integer configuration options that
|
||
** can be passed as the first argument to the [sqlite3_config()] interface.
|
||
**
|
||
** New configuration options may be added in future releases of SQLite.
|
||
** Existing configuration options might be discontinued. Applications
|
||
** should check the return code from [sqlite3_config()] to make sure that
|
||
** the call worked. The [sqlite3_config()] interface will return a
|
||
** non-zero [error code] if a discontinued or unsupported configuration option
|
||
** is invoked.
|
||
**
|
||
** <dl>
|
||
** [[SQLITE_CONFIG_SINGLETHREAD]] <dt>SQLITE_CONFIG_SINGLETHREAD</dt>
|
||
** <dd>There are no arguments to this option. ^This option sets the
|
||
** [threading mode] to Single-thread. In other words, it disables
|
||
** all mutexing and puts SQLite into a mode where it can only be used
|
||
** by a single thread. ^If SQLite is compiled with
|
||
** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then
|
||
** it is not possible to change the [threading mode] from its default
|
||
** value of Single-thread and so [sqlite3_config()] will return
|
||
** [SQLITE_ERROR] if called with the SQLITE_CONFIG_SINGLETHREAD
|
||
** configuration option.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_MULTITHREAD]] <dt>SQLITE_CONFIG_MULTITHREAD</dt>
|
||
** <dd>There are no arguments to this option. ^This option sets the
|
||
** [threading mode] to Multi-thread. In other words, it disables
|
||
** mutexing on [database connection] and [prepared statement] objects.
|
||
** The application is responsible for serializing access to
|
||
** [database connections] and [prepared statements]. But other mutexes
|
||
** are enabled so that SQLite will be safe to use in a multi-threaded
|
||
** environment as long as no two threads attempt to use the same
|
||
** [database connection] at the same time. ^If SQLite is compiled with
|
||
** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then
|
||
** it is not possible to set the Multi-thread [threading mode] and
|
||
** [sqlite3_config()] will return [SQLITE_ERROR] if called with the
|
||
** SQLITE_CONFIG_MULTITHREAD configuration option.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_SERIALIZED]] <dt>SQLITE_CONFIG_SERIALIZED</dt>
|
||
** <dd>There are no arguments to this option. ^This option sets the
|
||
** [threading mode] to Serialized. In other words, this option enables
|
||
** all mutexes including the recursive
|
||
** mutexes on [database connection] and [prepared statement] objects.
|
||
** In this mode (which is the default when SQLite is compiled with
|
||
** [SQLITE_THREADSAFE=1]) the SQLite library will itself serialize access
|
||
** to [database connections] and [prepared statements] so that the
|
||
** application is free to use the same [database connection] or the
|
||
** same [prepared statement] in different threads at the same time.
|
||
** ^If SQLite is compiled with
|
||
** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then
|
||
** it is not possible to set the Serialized [threading mode] and
|
||
** [sqlite3_config()] will return [SQLITE_ERROR] if called with the
|
||
** SQLITE_CONFIG_SERIALIZED configuration option.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_MALLOC]] <dt>SQLITE_CONFIG_MALLOC</dt>
|
||
** <dd> ^(This option takes a single argument which is a pointer to an
|
||
** instance of the [sqlite3_mem_methods] structure. The argument specifies
|
||
** alternative low-level memory allocation routines to be used in place of
|
||
** the memory allocation routines built into SQLite.)^ ^SQLite makes
|
||
** its own private copy of the content of the [sqlite3_mem_methods] structure
|
||
** before the [sqlite3_config()] call returns.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_GETMALLOC]] <dt>SQLITE_CONFIG_GETMALLOC</dt>
|
||
** <dd> ^(This option takes a single argument which is a pointer to an
|
||
** instance of the [sqlite3_mem_methods] structure. The [sqlite3_mem_methods]
|
||
** structure is filled with the currently defined memory allocation routines.)^
|
||
** This option can be used to overload the default memory allocation
|
||
** routines with a wrapper that simulations memory allocation failure or
|
||
** tracks memory usage, for example. </dd>
|
||
**
|
||
** [[SQLITE_CONFIG_MEMSTATUS]] <dt>SQLITE_CONFIG_MEMSTATUS</dt>
|
||
** <dd> ^This option takes single argument of type int, interpreted as a
|
||
** boolean, which enables or disables the collection of memory allocation
|
||
** statistics. ^(When memory allocation statistics are disabled, the
|
||
** following SQLite interfaces become non-operational:
|
||
** <ul>
|
||
** <li> [sqlite3_memory_used()]
|
||
** <li> [sqlite3_memory_highwater()]
|
||
** <li> [sqlite3_soft_heap_limit64()]
|
||
** <li> [sqlite3_status()]
|
||
** </ul>)^
|
||
** ^Memory allocation statistics are enabled by default unless SQLite is
|
||
** compiled with [SQLITE_DEFAULT_MEMSTATUS]=0 in which case memory
|
||
** allocation statistics are disabled by default.
|
||
** </dd>
|
||
**
|
||
** [[SQLITE_CONFIG_SCRATCH]] <dt>SQLITE_CONFIG_SCRATCH</dt>
|
||
** <dd> ^This option specifies a static memory buffer that SQLite can use for
|
||
** scratch memory. There are three arguments: A pointer an 8-byte
|
||
** aligned memory buffer from which the scratch allocations will be
|
||
** drawn, the size of each scratch allocation (sz),
|
||
** and the maximum number of scratch allocations (N). The sz
|
||
** argument must be a multiple of 16.
|
||
** The first argument must be a pointer to an 8-byte aligned buffer
|
||
** of at least sz*N bytes of memory.
|
||
** ^SQLite will use no more than two scratch buffers per thread. So
|
||
** N should be set to twice the expected maximum number of threads.
|
||
** ^SQLite will never require a scratch buffer that is more than 6
|
||
** times the database page size. ^If SQLite needs needs additional
|
||
** scratch memory beyond what is provided by this configuration option, then
|
||
** [sqlite3_malloc()] will be used to obtain the memory needed.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_PAGECACHE]] <dt>SQLITE_CONFIG_PAGECACHE</dt>
|
||
** <dd> ^This option specifies a static memory buffer that SQLite can use for
|
||
** the database page cache with the default page cache implementation.
|
||
** This configuration should not be used if an application-define page
|
||
** cache implementation is loaded using the SQLITE_CONFIG_PCACHE2 option.
|
||
** There are three arguments to this option: A pointer to 8-byte aligned
|
||
** memory, the size of each page buffer (sz), and the number of pages (N).
|
||
** The sz argument should be the size of the largest database page
|
||
** (a power of two between 512 and 32768) plus a little extra for each
|
||
** page header. ^The page header size is 20 to 40 bytes depending on
|
||
** the host architecture. ^It is harmless, apart from the wasted memory,
|
||
** to make sz a little too large. The first
|
||
** argument should point to an allocation of at least sz*N bytes of memory.
|
||
** ^SQLite will use the memory provided by the first argument to satisfy its
|
||
** memory needs for the first N pages that it adds to cache. ^If additional
|
||
** page cache memory is needed beyond what is provided by this option, then
|
||
** SQLite goes to [sqlite3_malloc()] for the additional storage space.
|
||
** The pointer in the first argument must
|
||
** be aligned to an 8-byte boundary or subsequent behavior of SQLite
|
||
** will be undefined.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_HEAP]] <dt>SQLITE_CONFIG_HEAP</dt>
|
||
** <dd> ^This option specifies a static memory buffer that SQLite will use
|
||
** for all of its dynamic memory allocation needs beyond those provided
|
||
** for by [SQLITE_CONFIG_SCRATCH] and [SQLITE_CONFIG_PAGECACHE].
|
||
** There are three arguments: An 8-byte aligned pointer to the memory,
|
||
** the number of bytes in the memory buffer, and the minimum allocation size.
|
||
** ^If the first pointer (the memory pointer) is NULL, then SQLite reverts
|
||
** to using its default memory allocator (the system malloc() implementation),
|
||
** undoing any prior invocation of [SQLITE_CONFIG_MALLOC]. ^If the
|
||
** memory pointer is not NULL and either [SQLITE_ENABLE_MEMSYS3] or
|
||
** [SQLITE_ENABLE_MEMSYS5] are defined, then the alternative memory
|
||
** allocator is engaged to handle all of SQLites memory allocation needs.
|
||
** The first pointer (the memory pointer) must be aligned to an 8-byte
|
||
** boundary or subsequent behavior of SQLite will be undefined.
|
||
** The minimum allocation size is capped at 2**12. Reasonable values
|
||
** for the minimum allocation size are 2**5 through 2**8.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_MUTEX]] <dt>SQLITE_CONFIG_MUTEX</dt>
|
||
** <dd> ^(This option takes a single argument which is a pointer to an
|
||
** instance of the [sqlite3_mutex_methods] structure. The argument specifies
|
||
** alternative low-level mutex routines to be used in place
|
||
** the mutex routines built into SQLite.)^ ^SQLite makes a copy of the
|
||
** content of the [sqlite3_mutex_methods] structure before the call to
|
||
** [sqlite3_config()] returns. ^If SQLite is compiled with
|
||
** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then
|
||
** the entire mutexing subsystem is omitted from the build and hence calls to
|
||
** [sqlite3_config()] with the SQLITE_CONFIG_MUTEX configuration option will
|
||
** return [SQLITE_ERROR].</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_GETMUTEX]] <dt>SQLITE_CONFIG_GETMUTEX</dt>
|
||
** <dd> ^(This option takes a single argument which is a pointer to an
|
||
** instance of the [sqlite3_mutex_methods] structure. The
|
||
** [sqlite3_mutex_methods]
|
||
** structure is filled with the currently defined mutex routines.)^
|
||
** This option can be used to overload the default mutex allocation
|
||
** routines with a wrapper used to track mutex usage for performance
|
||
** profiling or testing, for example. ^If SQLite is compiled with
|
||
** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then
|
||
** the entire mutexing subsystem is omitted from the build and hence calls to
|
||
** [sqlite3_config()] with the SQLITE_CONFIG_GETMUTEX configuration option will
|
||
** return [SQLITE_ERROR].</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_LOOKASIDE]] <dt>SQLITE_CONFIG_LOOKASIDE</dt>
|
||
** <dd> ^(This option takes two arguments that determine the default
|
||
** memory allocation for the lookaside memory allocator on each
|
||
** [database connection]. The first argument is the
|
||
** size of each lookaside buffer slot and the second is the number of
|
||
** slots allocated to each database connection.)^ ^(This option sets the
|
||
** <i>default</i> lookaside size. The [SQLITE_DBCONFIG_LOOKASIDE]
|
||
** verb to [sqlite3_db_config()] can be used to change the lookaside
|
||
** configuration on individual connections.)^ </dd>
|
||
**
|
||
** [[SQLITE_CONFIG_PCACHE2]] <dt>SQLITE_CONFIG_PCACHE2</dt>
|
||
** <dd> ^(This option takes a single argument which is a pointer to
|
||
** an [sqlite3_pcache_methods2] object. This object specifies the interface
|
||
** to a custom page cache implementation.)^ ^SQLite makes a copy of the
|
||
** object and uses it for page cache memory allocations.</dd>
|
||
**
|
||
** [[SQLITE_CONFIG_GETPCACHE2]] <dt>SQLITE_CONFIG_GETPCACHE2</dt>
|
||
** <dd> ^(This option takes a single argument which is a pointer to an
|
||
** [sqlite3_pcache_methods2] object. SQLite copies of the current
|
||
** page cache implementation into that object.)^ </dd>
|
||
**
|
||
** [[SQLITE_CONFIG_LOG]] <dt>SQLITE_CONFIG_LOG</dt>
|
||
** <dd> ^The SQLITE_CONFIG_LOG option takes two arguments: a pointer to a
|
||
** function with a call signature of void(*)(void*,int,const char*),
|
||
** and a pointer to void. ^If the function pointer is not NULL, it is
|
||
** invoked by [sqlite3_log()] to process each logging event. ^If the
|
||
** function pointer is NULL, the [sqlite3_log()] interface becomes a no-op.
|
||
** ^The void pointer that is the second argument to SQLITE_CONFIG_LOG is
|
||
** passed through as the first parameter to the application-defined logger
|
||
** function whenever that function is invoked. ^The second parameter to
|
||
** the logger function is a copy of the first parameter to the corresponding
|
||
** [sqlite3_log()] call and is intended to be a [result code] or an
|
||
** [extended result code]. ^The third parameter passed to the logger is
|
||
** log message after formatting via [sqlite3_snprintf()].
|
||
** The SQLite logging interface is not reentrant; the logger function
|
||
** supplied by the application must not invoke any SQLite interface.
|
||
** In a multi-threaded application, the application-defined logger
|
||
** function must be threadsafe. </dd>
|
||
**
|
||
** [[SQLITE_CONFIG_URI]] <dt>SQLITE_CONFIG_URI
|
||
** <dd> This option takes a single argument of type int. If non-zero, then
|
||
** URI handling is globally enabled. If the parameter is zero, then URI handling
|
||
** is globally disabled. If URI handling is globally enabled, all filenames
|
||
** passed to [sqlite3_open()], [sqlite3_open_v2()], [sqlite3_open16()] or
|
||
** specified as part of [ATTACH] commands are interpreted as URIs, regardless
|
||
** of whether or not the [SQLITE_OPEN_URI] flag is set when the database
|
||
** connection is opened. If it is globally disabled, filenames are
|
||
** only interpreted as URIs if the SQLITE_OPEN_URI flag is set when the
|
||
** database connection is opened. By default, URI handling is globally
|
||
** disabled. The default value may be changed by compiling with the
|
||
** [SQLITE_USE_URI] symbol defined.
|
||
**
|
||
** [[SQLITE_CONFIG_COVERING_INDEX_SCAN]] <dt>SQLITE_CONFIG_COVERING_INDEX_SCAN
|
||
** <dd> This option takes a single integer argument which is interpreted as
|
||
** a boolean in order to enable or disable the use of covering indices for
|
||
** full table scans in the query optimizer. The default setting is determined
|
||
** by the [SQLITE_ALLOW_COVERING_INDEX_SCAN] compile-time option, or is "on"
|
||
** if that compile-time option is omitted.
|
||
** The ability to disable the use of covering indices for full table scans
|
||
** is because some incorrectly coded legacy applications might malfunction
|
||
** malfunction when the optimization is enabled. Providing the ability to
|
||
** disable the optimization allows the older, buggy application code to work
|
||
** without change even with newer versions of SQLite.
|
||
**
|
||
** [[SQLITE_CONFIG_PCACHE]] [[SQLITE_CONFIG_GETPCACHE]]
|
||
** <dt>SQLITE_CONFIG_PCACHE and SQLITE_CONFIG_GETPCACHE
|
||
** <dd> These options are obsolete and should not be used by new code.
|
||
** They are retained for backwards compatibility but are now no-ops.
|
||
** </dl>
|
||
**
|
||
** [[SQLITE_CONFIG_SQLLOG]]
|
||
** <dt>SQLITE_CONFIG_SQLLOG
|
||
** <dd>This option is only available if sqlite is compiled with the
|
||
** SQLITE_ENABLE_SQLLOG pre-processor macro defined. The first argument should
|
||
** be a pointer to a function of type void(*)(void*,sqlite3*,const char*, int).
|
||
** The second should be of type (void*). The callback is invoked by the library
|
||
** in three separate circumstances, identified by the value passed as the
|
||
** fourth parameter. If the fourth parameter is 0, then the database connection
|
||
** passed as the second argument has just been opened. The third argument
|
||
** points to a buffer containing the name of the main database file. If the
|
||
** fourth parameter is 1, then the SQL statement that the third parameter
|
||
** points to has just been executed. Or, if the fourth parameter is 2, then
|
||
** the connection being passed as the second parameter is being closed. The
|
||
** third parameter is passed NULL In this case.
|
||
** </dl>
|
||
*/
|
||
#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 /* no-op */
|
||
#define SQLITE_CONFIG_GETPCACHE 15 /* no-op */
|
||
#define SQLITE_CONFIG_LOG 16 /* xFunc, void* */
|
||
#define SQLITE_CONFIG_URI 17 /* int */
|
||
#define SQLITE_CONFIG_PCACHE2 18 /* sqlite3_pcache_methods2* */
|
||
#define SQLITE_CONFIG_GETPCACHE2 19 /* sqlite3_pcache_methods2* */
|
||
#define SQLITE_CONFIG_COVERING_INDEX_SCAN 20 /* int */
|
||
#define SQLITE_CONFIG_SQLLOG 21 /* xSqllog, void* */
|
||
|
||
/*
|
||
** CAPI3REF: Database Connection Configuration Options
|
||
**
|
||
** These constants are the available integer configuration options that
|
||
** can be passed as the second argument to the [sqlite3_db_config()] interface.
|
||
**
|
||
** New configuration options may be added in future releases of SQLite.
|
||
** Existing configuration options might be discontinued. Applications
|
||
** should check the return code from [sqlite3_db_config()] to make sure that
|
||
** the call worked. ^The [sqlite3_db_config()] interface will return a
|
||
** non-zero [error code] if a discontinued or unsupported configuration option
|
||
** is invoked.
|
||
**
|
||
** <dl>
|
||
** <dt>SQLITE_DBCONFIG_LOOKASIDE</dt>
|
||
** <dd> ^This option takes three additional arguments that determine the
|
||
** [lookaside memory allocator] configuration for the [database connection].
|
||
** ^The first argument (the third parameter to [sqlite3_db_config()] is a
|
||
** pointer to a memory buffer to use for lookaside memory.
|
||
** ^The first argument after the SQLITE_DBCONFIG_LOOKASIDE verb
|
||
** may be NULL in which case SQLite will allocate the
|
||
** lookaside buffer itself using [sqlite3_malloc()]. ^The second argument is the
|
||
** size of each lookaside buffer slot. ^The third argument is the number of
|
||
** slots. The size of the buffer in the first argument must be greater than
|
||
** or equal to the product of the second and third arguments. The buffer
|
||
** must be aligned to an 8-byte boundary. ^If the second argument to
|
||
** SQLITE_DBCONFIG_LOOKASIDE is not a multiple of 8, it is internally
|
||
** rounded down to the next smaller multiple of 8. ^(The lookaside memory
|
||
** configuration for a database connection can only be changed when that
|
||
** connection is not currently using lookaside memory, or in other words
|
||
** when the "current value" returned by
|
||
** [sqlite3_db_status](D,[SQLITE_CONFIG_LOOKASIDE],...) is zero.
|
||
** Any attempt to change the lookaside memory configuration when lookaside
|
||
** memory is in use leaves the configuration unchanged and returns
|
||
** [SQLITE_BUSY].)^</dd>
|
||
**
|
||
** <dt>SQLITE_DBCONFIG_ENABLE_FKEY</dt>
|
||
** <dd> ^This option is used to enable or disable the enforcement of
|
||
** [foreign key constraints]. There should be two additional arguments.
|
||
** The first argument is an integer which is 0 to disable FK enforcement,
|
||
** positive to enable FK enforcement or negative to leave FK enforcement
|
||
** unchanged. The second parameter is a pointer to an integer into which
|
||
** is written 0 or 1 to indicate whether FK enforcement is off or on
|
||
** following this call. The second parameter may be a NULL pointer, in
|
||
** which case the FK enforcement setting is not reported back. </dd>
|
||
**
|
||
** <dt>SQLITE_DBCONFIG_ENABLE_TRIGGER</dt>
|
||
** <dd> ^This option is used to enable or disable [CREATE TRIGGER | triggers].
|
||
** There should be two additional arguments.
|
||
** The first argument is an integer which is 0 to disable triggers,
|
||
** positive to enable triggers or negative to leave the setting unchanged.
|
||
** The second parameter is a pointer to an integer into which
|
||
** is written 0 or 1 to indicate whether triggers are disabled or enabled
|
||
** following this call. The second parameter may be a NULL pointer, in
|
||
** which case the trigger setting is not reported back. </dd>
|
||
**
|
||
** </dl>
|
||
*/
|
||
#define SQLITE_DBCONFIG_LOOKASIDE 1001 /* void* int int */
|
||
#define SQLITE_DBCONFIG_ENABLE_FKEY 1002 /* int int* */
|
||
#define SQLITE_DBCONFIG_ENABLE_TRIGGER 1003 /* int int* */
|
||
|
||
|
||
/*
|
||
** CAPI3REF: Enable Or Disable Extended Result Codes
|
||
**
|
||
** ^The sqlite3_extended_result_codes() routine enables or disables the
|
||
** [extended result codes] feature of SQLite. ^The extended result
|
||
** codes are disabled by default for historical compatibility.
|
||
*/
|
||
SQLITE_API int sqlite3_extended_result_codes(sqlite3*, int onoff);
|
||
|
||
/*
|
||
** CAPI3REF: Last Insert Rowid
|
||
**
|
||
** ^Each entry in an SQLite table has a unique 64-bit signed
|
||
** integer key called the [ROWID | "rowid"]. ^The rowid is always available
|
||
** as an undeclared column named ROWID, OID, or _ROWID_ as long as those
|
||
** names are not also used by explicitly declared columns. ^If
|
||
** the table has a column of type [INTEGER PRIMARY KEY] then that column
|
||
** is another alias for the rowid.
|
||
**
|
||
** ^This routine returns the [rowid] of the most recent
|
||
** successful [INSERT] into the database from the [database connection]
|
||
** in the first argument. ^As of SQLite version 3.7.7, this routines
|
||
** records the last insert rowid of both ordinary tables and [virtual tables].
|
||
** ^If no successful [INSERT]s
|
||
** have ever occurred on that database connection, zero is returned.
|
||
**
|
||
** ^(If an [INSERT] occurs within a trigger or within a [virtual table]
|
||
** method, then this routine will return the [rowid] of the inserted
|
||
** row as long as the trigger or virtual table method is running.
|
||
** But once the trigger or virtual table method ends, the value returned
|
||
** by this routine reverts to what it was before the trigger or virtual
|
||
** table method began.)^
|
||
**
|
||
** ^An [INSERT] that fails due to a constraint violation is not a
|
||
** successful [INSERT] and does not change the value returned by this
|
||
** routine. ^Thus INSERT OR FAIL, INSERT OR IGNORE, INSERT OR ROLLBACK,
|
||
** and INSERT OR ABORT make no changes to the return value of this
|
||
** routine when their insertion fails. ^(When INSERT OR REPLACE
|
||
** encounters a constraint violation, it does not fail. The
|
||
** INSERT continues to completion after deleting rows that caused
|
||
** the constraint problem so INSERT OR REPLACE will always change
|
||
** the return value of this interface.)^
|
||
**
|
||
** ^For the purposes of this routine, an [INSERT] is considered to
|
||
** be successful even if it is subsequently rolled back.
|
||
**
|
||
** This function is accessible to SQL statements via the
|
||
** [last_insert_rowid() SQL function].
|
||
**
|
||
** If a separate thread performs a new [INSERT] on the same
|
||
** database connection while the [sqlite3_last_insert_rowid()]
|
||
** function is running and thus changes the last insert [rowid],
|
||
** then the value returned by [sqlite3_last_insert_rowid()] is
|
||
** unpredictable and might not equal either the old or the new
|
||
** last insert [rowid].
|
||
*/
|
||
SQLITE_API sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*);
|
||
|
||
/*
|
||
** CAPI3REF: Count The Number Of Rows Modified
|
||
**
|
||
** ^This function returns the number of database rows that were changed
|
||
** or inserted or deleted by the most recently completed SQL statement
|
||
** on the [database connection] specified by the first parameter.
|
||
** ^(Only changes that are directly specified by the [INSERT], [UPDATE],
|
||
** or [DELETE] statement are counted. Auxiliary changes caused by
|
||
** triggers or [foreign key actions] are not counted.)^ Use the
|
||
** [sqlite3_total_changes()] function to find the total number of changes
|
||
** including changes caused by triggers and foreign key actions.
|
||
**
|
||
** ^Changes to a view that are simulated by an [INSTEAD OF trigger]
|
||
** are not counted. Only real table changes are counted.
|
||
**
|
||
** ^(A "row change" is a change to a single row of a single table
|
||
** caused by an INSERT, DELETE, or UPDATE statement. Rows that
|
||
** are changed as side effects of [REPLACE] constraint resolution,
|
||
** rollback, ABORT processing, [DROP TABLE], or by any other
|
||
** mechanisms do not count as direct row changes.)^
|
||
**
|
||
** A "trigger context" is a scope of execution that begins and
|
||
** ends with the script of a [CREATE TRIGGER | trigger].
|
||
** Most SQL statements are
|
||
** evaluated outside of any trigger. This is the "top level"
|
||
** trigger context. If a trigger fires from the top level, a
|
||
** new trigger context is entered for the duration of that one
|
||
** trigger. Subtriggers create subcontexts for their duration.
|
||
**
|
||
** ^Calling [sqlite3_exec()] or [sqlite3_step()] recursively does
|
||
** not create a new trigger context.
|
||
**
|
||
** ^This function returns the number of direct row changes in the
|
||
** most recent INSERT, UPDATE, or DELETE statement within the same
|
||
** trigger context.
|
||
**
|
||
** ^Thus, when called from the top level, this function returns the
|
||
** number of changes in the most recent INSERT, UPDATE, or DELETE
|
||
** that also occurred at the top level. ^(Within the body of a trigger,
|
||
** the sqlite3_changes() interface can be called to find the number of
|
||
** changes in the most recently completed INSERT, UPDATE, or DELETE
|
||
** statement within the body of the same trigger.
|
||
** However, the number returned does not include changes
|
||
** caused by subtriggers since those have their own context.)^
|
||
**
|
||
** See also the [sqlite3_total_changes()] interface, the
|
||
** [count_changes pragma], and the [changes() SQL function].
|
||
**
|
||
** If a separate thread makes changes on the same database connection
|
||
** while [sqlite3_changes()] is running then the value returned
|
||
** is unpredictable and not meaningful.
|
||
*/
|
||
SQLITE_API int sqlite3_changes(sqlite3*);
|
||
|
||
/*
|
||
** CAPI3REF: Total Number Of Rows Modified
|
||
**
|
||
** ^This function returns the number of row changes caused by [INSERT],
|
||
** [UPDATE] or [DELETE] statements since the [database connection] was opened.
|
||
** ^(The count returned by sqlite3_total_changes() includes all changes
|
||
** from all [CREATE TRIGGER | trigger] contexts and changes made by
|
||
** [foreign key actions]. However,
|
||
** the count does not include changes used to implement [REPLACE] constraints,
|
||
** do rollbacks or ABORT processing, or [DROP TABLE] processing. The
|
||
** count does not include rows of views that fire an [INSTEAD OF trigger],
|
||
** though if the INSTEAD OF trigger makes changes of its own, those changes
|
||
** are counted.)^
|
||
** ^The sqlite3_total_changes() function counts the changes as soon as
|
||
** the statement that makes them is completed (when the statement handle
|
||
** is passed to [sqlite3_reset()] or [sqlite3_finalize()]).
|
||
**
|
||
** See also the [sqlite3_changes()] interface, the
|
||
** [count_changes pragma], and the [total_changes() SQL function].
|
||
**
|
||
** If a separate thread makes changes on the same database connection
|
||
** while [sqlite3_total_changes()] is running then the value
|
||
** returned is unpredictable and not meaningful.
|
||
*/
|
||
SQLITE_API int sqlite3_total_changes(sqlite3*);
|
||
|
||
/*
|
||
** CAPI3REF: Interrupt A Long-Running Query
|
||
**
|
||
** ^This function causes any pending database operation to abort and
|
||
** return at its earliest opportunity. This routine is typically
|
||
** called in response to a user action such as pressing "Cancel"
|
||
** or Ctrl-C where the user wants a long query operation to halt
|
||
** immediately.
|
||
**
|
||
** ^It is safe to call this routine from a thread different from the
|
||
** thread that is currently running the database operation. But it
|
||
** is not safe to call this routine with a [database connection] that
|
||
** is closed or might close before sqlite3_interrupt() returns.
|
||
**
|
||
** ^If an SQL operation is very nearly finished at the time when
|
||
** sqlite3_interrupt() is called, then it might not have an opportunity
|
||
** to be interrupted and might continue to completion.
|
||
**
|
||
** ^An SQL operation that is interrupted will return [SQLITE_INTERRUPT].
|
||
** ^If the interrupted SQL operation is an INSERT, UPDATE, or DELETE
|
||
** that is inside an explicit transaction, then the entire transaction
|
||
** will be rolled back automatically.
|
||
**
|
||
** ^The sqlite3_interrupt(D) call is in effect until all currently running
|
||
** SQL statements on [database connection] D complete. ^Any new SQL statements
|
||
** that are started after the sqlite3_interrupt() call and before the
|
||
** running statements reaches zero are interrupted as if they had been
|
||
** running prior to the sqlite3_interrupt() call. ^New SQL statements
|
||
** that are started after the running statement count reaches zero are
|
||
** not effected by the sqlite3_interrupt().
|
||
** ^A call to sqlite3_interrupt(D) that occurs when there are no running
|
||
** SQL statements is a no-op and has no effect on SQL statements
|
||
** that are started after the sqlite3_interrupt() call returns.
|
||
**
|
||
** If the database connection closes while [sqlite3_interrupt()]
|
||
** is running then bad things will likely happen.
|
||
*/
|
||
SQLITE_API void sqlite3_interrupt(sqlite3*);
|
||
|
||
/*
|
||
** CAPI3REF: Determine If An SQL Statement Is Complete
|
||
**
|
||
** These routines are useful during command-line input to determine if the
|
||
** currently entered text seems to form a complete SQL statement or
|
||
** if additional input is needed before sending the text into
|
||
** SQLite for parsing. ^These routines return 1 if the input string
|
||
** appears to be a complete SQL statement. ^A statement is judged to be
|
||
** complete if it ends with a semicolon token and is not a prefix of a
|
||
** well-formed CREATE TRIGGER statement. ^Semicolons that are embedded within
|
||
** string literals or quoted identifier names or comments are not
|
||
** independent tokens (they are part of the token in which they are
|
||
** embedded) and thus do not count as a statement terminator. ^Whitespace
|
||
** and comments that follow the final semicolon are ignored.
|
||
**
|
||
** ^These routines return 0 if the statement is incomplete. ^If a
|
||
** memory allocation fails, then SQLITE_NOMEM is returned.
|
||
**
|
||
** ^These routines do not parse the SQL statements thus
|
||
** will not detect syntactically incorrect SQL.
|
||
**
|
||
** ^(If SQLite has not been initialized using [sqlite3_initialize()] prior
|
||
** to invoking sqlite3_complete16() then sqlite3_initialize() is invoked
|
||
** automatically by sqlite3_complete16(). If that initialization fails,
|
||
** then the return value from sqlite3_complete16() will be non-zero
|
||
** regardless of whether or not the input SQL is complete.)^
|
||
**
|
||
** The input to [sqlite3_complete()] must be a zero-terminated
|
||
** UTF-8 string.
|
||
**
|
||
** The input to [sqlite3_complete16()] must be a zero-terminated
|
||
** UTF-16 string in native byte order.
|
||
*/
|
||
SQLITE_API int sqlite3_complete(const char *sql);
|
||
SQLITE_API int sqlite3_complete16(const void *sql);
|
||
|
||
/*
|
||
** CAPI3REF: Register A Callback To Handle SQLITE_BUSY Errors
|
||
**
|
||
** ^This routine sets a callback function that might be invoked whenever
|
||
** an attempt is made to open a database table that another thread
|
||
** or process has locked.
|
||
**
|
||
** ^If the busy callback is NULL, then [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED]
|
||
** is returned immediately upon encountering the lock. ^If the busy callback
|
||
** is not NULL, then the callback might be invoked with two arguments.
|
||
**
|
||
** ^The first argument to the busy handler is a copy of the void* pointer which
|
||
** is the third argument to sqlite3_busy_handler(). ^The second argument to
|
||
** the busy handler callback is the number of times that the busy handler has
|
||
** been invoked for this locking event. ^If the
|
||
** busy callback returns 0, then no additional attempts are made to
|
||
** access the database and [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED] is returned.
|
||
** ^If the callback returns non-zero, then another attempt
|
||
** is made to open the database for reading and the cycle repeats.
|
||
**
|
||
** The presence of a busy handler does not guarantee that it will be invoked
|
||
** when there is lock contention. ^If SQLite determines that invoking the busy
|
||
** handler could result in a deadlock, it will go ahead and return [SQLITE_BUSY]
|
||
** or [SQLITE_IOERR_BLOCKED] instead of invoking the busy handler.
|
||
** Consider a scenario where one process is holding a read lock that
|
||
** it is trying to promote to a reserved lock and
|
||
** a second process is holding a reserved lock that it is trying
|
||
** to promote to an exclusive lock. The first process cannot proceed
|
||
** because it is blocked by the second and the second process cannot
|
||
** proceed because it is blocked by the first. If both processes
|
||
** invoke the busy handlers, neither will make any progress. Therefore,
|
||
** SQLite returns [SQLITE_BUSY] for the first process, hoping that this
|
||
** will induce the first process to release its read lock and allow
|
||
** the second process to proceed.
|
||
**
|
||
** ^The default busy callback is NULL.
|
||
**
|
||
** ^The [SQLITE_BUSY] error is converted to [SQLITE_IOERR_BLOCKED]
|
||
** when SQLite is in the middle of a large transaction where all the
|
||
** changes will not fit into the in-memory cache. SQLite will
|
||
** already hold a RESERVED lock on the database file, but it needs
|
||
** to promote this lock to EXCLUSIVE so that it can spill cache
|
||
** pages into the database file without harm to concurrent
|
||
** readers. ^If it is unable to promote the lock, then the in-memory
|
||
** cache will be left in an inconsistent state and so the error
|
||
** code is promoted from the relatively benign [SQLITE_BUSY] to
|
||
** the more severe [SQLITE_IOERR_BLOCKED]. ^This error code promotion
|
||
** forces an automatic rollback of the changes. See the
|
||
** <a href="/cvstrac/wiki?p=CorruptionFollowingBusyError">
|
||
** CorruptionFollowingBusyError</a> wiki page for a discussion of why
|
||
** this is important.
|
||
**
|
||
** ^(There can only be a single busy handler defined for each
|
||
** [database connection]. Setting a new busy handler clears any
|
||
** previously set handler.)^ ^Note that calling [sqlite3_busy_timeout()]
|
||
** will also set or clear the busy handler.
|
||
**
|
||
** The busy callback should not take any actions which modify the
|
||
** database connection that invoked the busy handler. Any such actions
|
||
** result in undefined behavior.
|
||
**
|
||
** A busy handler must not close the database connection
|
||
** or [prepared statement] that invoked the busy handler.
|
||
*/
|
||
SQLITE_API int sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*);
|
||
|
||
/*
|
||
** CAPI3REF: Set A Busy Timeout
|
||
**
|
||
** ^This routine sets a [sqlite3_busy_handler | busy handler] that sleeps
|
||
** for a specified amount of time when a table is locked. ^The handler
|
||
** will sleep multiple times until at least "ms" milliseconds of sleeping
|
||
** have accumulated. ^After at least "ms" milliseconds of sleeping,
|
||
** the handler returns 0 which causes [sqlite3_step()] to return
|
||
** [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED].
|
||
**
|
||
** ^Calling this routine with an argument less than or equal to zero
|
||
** turns off all busy handlers.
|
||
**
|
||
** ^(There can only be a single busy handler for a particular
|
||
** [database connection] any any given moment. If another busy handler
|
||
** was defined (using [sqlite3_busy_handler()]) prior to calling
|
||
** this routine, that other busy handler is cleared.)^
|
||
*/
|
||
SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms);
|
||
|
||
/*
|
||
** CAPI3REF: Convenience Routines For Running Queries
|
||
**
|
||
** This is a legacy interface that is preserved for backwards compatibility.
|
||
** Use of this interface is not recommended.
|
||
**
|
||
** Definition: A <b>result table</b> is memory data structure created by the
|
||
** [sqlite3_get_table()] interface. A result table records the
|
||
** complete query results from one or more queries.
|
||
**
|
||
** The table conceptually has a number of rows and columns. But
|
||
** these numbers are not part of the result table itself. These
|
||
** numbers are obtained separately. Let N be the number of rows
|
||
** and M be the number of columns.
|
||
**
|
||
** A result table is an array of pointers to zero-terminated UTF-8 strings.
|
||
** There are (N+1)*M elements in the array. The first M pointers point
|
||
** to zero-terminated strings that contain the names of the columns.
|
||
** The remaining entries all point to query results. NULL values result
|
||
** in NULL pointers. All other values are in their UTF-8 zero-terminated
|
||
** string representation as returned by [sqlite3_column_text()].
|
||
**
|
||
** A result table might consist of one or more memory allocations.
|
||
** It is not safe to pass a result table directly to [sqlite3_free()].
|
||
** A result table should be deallocated using [sqlite3_free_table()].
|
||
**
|
||
** ^(As an example of the result table format, suppose a query result
|
||
** is as follows:
|
||
**
|
||
** <blockquote><pre>
|
||
** Name | Age
|
||
** -----------------------
|
||
** Alice | 43
|
||
** Bob | 28
|
||
** Cindy | 21
|
||
** </pre></blockquote>
|
||
**
|
||
** There are two column (M==2) and three rows (N==3). Thus the
|
||
** result table has 8 entries. Suppose the result table is stored
|
||
** in an array names azResult. Then azResult holds this content:
|
||
**
|
||
** <blockquote><pre>
|
||
** azResult[0] = "Name";
|
||
** azResult[1] = "Age";
|
||
** azResult[2] = "Alice";
|
||
** azResult[3] = "43";
|
||
** azResult[4] = "Bob";
|
||
** azResult[5] = "28";
|
||
** azResult[6] = "Cindy";
|
||
** azResult[7] = "21";
|
||
** </pre></blockquote>)^
|
||
**
|
||
** ^The sqlite3_get_table() function evaluates one or more
|
||
** semicolon-separated SQL statements in the zero-terminated UTF-8
|
||
** string of its 2nd parameter and returns a result table to the
|
||
** pointer given in its 3rd parameter.
|
||
**
|
||
** After the application has finished with the result from sqlite3_get_table(),
|
||
** it must pass the result table pointer to sqlite3_free_table() in order to
|
||
** release the memory that was malloced. Because of the way the
|
||
** [sqlite3_malloc()] happens within sqlite3_get_table(), the calling
|
||
** function must not try to call [sqlite3_free()] directly. Only
|
||
** [sqlite3_free_table()] is able to release the memory properly and safely.
|
||
**
|
||
** The sqlite3_get_table() interface is implemented as a wrapper around
|
||
** [sqlite3_exec()]. The sqlite3_get_table() routine does not have access
|
||
** to any internal data structures of SQLite. It uses only the public
|
||
** interface defined here. As a consequence, errors that occur in the
|
||
** wrapper layer outside of the internal [sqlite3_exec()] call are not
|
||
** reflected in subsequent calls to [sqlite3_errcode()] or
|
||
** [sqlite3_errmsg()].
|
||
*/
|
||
SQLITE_API 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 */
|
||
);
|
||
SQLITE_API void sqlite3_free_table(char **result);
|
||
|
||
/*
|
||
** CAPI3REF: Formatted String Printing Functions
|
||
**
|
||
** These routines are work-alikes of the "printf()" family of functions
|
||
** from the standard C library.
|
||
**
|
||
** ^The sqlite3_mprintf() and sqlite3_vmprintf() routines write their
|
||
** results into memory obtained from [sqlite3_malloc()].
|
||
** The strings returned by these two routines should be
|
||
** released by [sqlite3_free()]. ^Both routines return a
|
||
** NULL pointer if [sqlite3_malloc()] is unable to allocate enough
|
||
** memory to hold the resulting string.
|
||
**
|
||
** ^(The sqlite3_snprintf() routine is similar to "snprintf()" from
|
||
** the standard C library. The result is written into the
|
||
** buffer supplied as the second parameter whose size is given by
|
||
** the first parameter. Note that the order of the
|
||
** first two parameters is reversed from snprintf().)^ This is an
|
||
** historical accident that cannot be fixed without breaking
|
||
** backwards compatibility. ^(Note also that sqlite3_snprintf()
|
||
** returns a pointer to its buffer instead of the number of
|
||
** characters actually written into the buffer.)^ We admit that
|
||
** the number of characters written would be a more useful return
|
||
** value but we cannot change the implementation of sqlite3_snprintf()
|
||
** now without breaking compatibility.
|
||
**
|
||
** ^As long as the buffer size is greater than zero, sqlite3_snprintf()
|
||
** guarantees that the buffer is always zero-terminated. ^The first
|
||
** parameter "n" is the total size of the buffer, including space for
|
||
** the zero terminator. So the longest string that can be completely
|
||
** written will be n-1 characters.
|
||
**
|
||
** ^The sqlite3_vsnprintf() routine is a varargs version of sqlite3_snprintf().
|
||
**
|
||
** These routines all implement some additional formatting
|
||
** options that are useful for constructing SQL statements.
|
||
** All of the usual printf() formatting options apply. In addition, there
|
||
** is are "%q", "%Q", and "%z" options.
|
||
**
|
||
** ^(The %q option works like %s in that it substitutes a nul-terminated
|
||
** string from the argument list. But %q also doubles every '\'' character.
|
||
** %q is designed for use inside a string literal.)^ By doubling each '\''
|
||
** character it escapes that character and allows it to be inserted into
|
||
** the string.
|
||
**
|
||
** For example, assume the string variable zText contains text as follows:
|
||
**
|
||
** <blockquote><pre>
|
||
** char *zText = "It's a happy day!";
|
||
** </pre></blockquote>
|
||
**
|
||
** One can use this text in an SQL statement as follows:
|
||
**
|
||
** <blockquote><pre>
|
||
** char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES('%q')", zText);
|
||
** sqlite3_exec(db, zSQL, 0, 0, 0);
|
||
** sqlite3_free(zSQL);
|
||
** </pre></blockquote>
|
||
**
|
||
** Because the %q format string is used, the '\'' character in zText
|
||
** is escaped and the SQL generated is as follows:
|
||
**
|
||
** <blockquote><pre>
|
||
** INSERT INTO table1 VALUES('It''s a happy day!')
|
||
** </pre></blockquote>
|
||
**
|
||
** This is correct. Had we used %s instead of %q, the generated SQL
|
||
** would have looked like this:
|
||
**
|
||
** <blockquote><pre>
|
||
** INSERT INTO table1 VALUES('It's a happy day!');
|
||
** </pre></blockquote>
|
||
**
|
||
** This second example is an SQL syntax error. As a general rule you should
|
||
** always use %q instead of %s when inserting text into a string literal.
|
||
**
|
||
** ^(The %Q option works like %q except it also adds single quotes around
|
||
** the outside of the total string. Additionally, if the parameter in the
|
||
** argument list is a NULL pointer, %Q substitutes the text "NULL" (without
|
||
** single quotes).)^ So, for example, one could say:
|
||
**
|
||
** <blockquote><pre>
|
||
** char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES(%Q)", zText);
|
||
** sqlite3_exec(db, zSQL, 0, 0, 0);
|
||
** sqlite3_free(zSQL);
|
||
** </pre></blockquote>
|
||
**
|
||
** The code above will render a correct SQL statement in the zSQL
|
||
** variable even if the zText variable is a NULL pointer.
|
||
**
|
||
** ^(The "%z" formatting option works like "%s" but with the
|
||
** addition that after the string has been read and copied into
|
||
** the result, [sqlite3_free()] is called on the input string.)^
|
||
*/
|
||
SQLITE_API char *sqlite3_mprintf(const char*,...);
|
||
SQLITE_API char *sqlite3_vmprintf(const char*, va_list);
|
||
SQLITE_API char *sqlite3_snprintf(int,char*,const char*, ...);
|
||
SQLITE_API char *sqlite3_vsnprintf(int,char*,const char*, va_list);
|
||
|
||
/*
|
||
** CAPI3REF: Memory Allocation Subsystem
|
||
**
|
||
** The SQLite core uses these three routines for all of its own
|
||
** internal memory allocation needs. "Core" in the previous sentence
|
||
** does not include operating-system specific VFS implementation. The
|
||
** Windows VFS uses native malloc() and free() for some operations.
|
||
**
|
||
** ^The sqlite3_malloc() routine returns a pointer to a block
|
||
** of memory at least N bytes in length, where N is the parameter.
|
||
** ^If sqlite3_malloc() is unable to obtain sufficient free
|
||
** memory, it returns a NULL pointer. ^If the parameter N to
|
||
** sqlite3_malloc() is zero or negative then sqlite3_malloc() returns
|
||
** a NULL pointer.
|
||
**
|
||
** ^Calling sqlite3_free() with a pointer previously returned
|
||
** by sqlite3_malloc() or sqlite3_realloc() releases that memory so
|
||
** that it might be reused. ^The sqlite3_free() routine is
|
||
** a no-op if is called with a NULL pointer. Passing a NULL pointer
|
||
** to sqlite3_free() is harmless. After being freed, memory
|
||
** should neither be read nor written. Even reading previously freed
|
||
** memory might result in a segmentation fault or other severe error.
|
||
** Memory corruption, a segmentation fault, or other severe error
|
||
** might result if sqlite3_free() is called with a non-NULL pointer that
|
||
** was not obtained from sqlite3_malloc() or sqlite3_realloc().
|
||
**
|
||
** ^(The sqlite3_realloc() interface attempts to resize a
|
||
** prior memory allocation to be at least N bytes, where N is the
|
||
** second parameter. The memory allocation to be resized is the first
|
||
** parameter.)^ ^ If the first parameter to sqlite3_realloc()
|
||
** is a NULL pointer then its behavior is identical to calling
|
||
** sqlite3_malloc(N) where N is the second parameter to sqlite3_realloc().
|
||
** ^If the second parameter to sqlite3_realloc() is zero or
|
||
** negative then the behavior is exactly the same as calling
|
||
** sqlite3_free(P) where P is the first parameter to sqlite3_realloc().
|
||
** ^sqlite3_realloc() returns a pointer to a memory allocation
|
||
** of at least N bytes in size or NULL if sufficient memory is unavailable.
|
||
** ^If M is the size of the prior allocation, then min(N,M) bytes
|
||
** of the prior allocation are copied into the beginning of buffer returned
|
||
** by sqlite3_realloc() and the prior allocation is freed.
|
||
** ^If sqlite3_realloc() returns NULL, then the prior allocation
|
||
** is not freed.
|
||
**
|
||
** ^The memory returned by sqlite3_malloc() and sqlite3_realloc()
|
||
** is always aligned to at least an 8 byte boundary, or to a
|
||
** 4 byte boundary if the [SQLITE_4_BYTE_ALIGNED_MALLOC] compile-time
|
||
** option is used.
|
||
**
|
||
** In SQLite version 3.5.0 and 3.5.1, it was possible to define
|
||
** the SQLITE_OMIT_MEMORY_ALLOCATION which would cause the built-in
|
||
** implementation of these routines to be omitted. That capability
|
||
** is no longer provided. Only built-in memory allocators can be used.
|
||
**
|
||
** Prior to SQLite version 3.7.10, the Windows OS interface layer called
|
||
** the system malloc() and free() directly when converting
|
||
** filenames between the UTF-8 encoding used by SQLite
|
||
** and whatever filename encoding is used by the particular Windows
|
||
** installation. Memory allocation errors were detected, but
|
||
** they were reported back as [SQLITE_CANTOPEN] or
|
||
** [SQLITE_IOERR] rather than [SQLITE_NOMEM].
|
||
**
|
||
** The pointer arguments to [sqlite3_free()] and [sqlite3_realloc()]
|
||
** must be either NULL or else pointers obtained from a prior
|
||
** invocation of [sqlite3_malloc()] or [sqlite3_realloc()] that have
|
||
** not yet been released.
|
||
**
|
||
** The application must not read or write any part of
|
||
** a block of memory after it has been released using
|
||
** [sqlite3_free()] or [sqlite3_realloc()].
|
||
*/
|
||
SQLITE_API void *sqlite3_malloc(int);
|
||
SQLITE_API void *sqlite3_realloc(void*, int);
|
||
SQLITE_API void sqlite3_free(void*);
|
||
|
||
/*
|
||
** CAPI3REF: Memory Allocator Statistics
|
||
**
|
||
** SQLite provides these two interfaces for reporting on the status
|
||
** of the [sqlite3_malloc()], [sqlite3_free()], and [sqlite3_realloc()]
|
||
** routines, which form the built-in memory allocation subsystem.
|
||
**
|
||
** ^The [sqlite3_memory_used()] routine returns the number of bytes
|
||
** of memory currently outstanding (malloced but not freed).
|
||
** ^The [sqlite3_memory_highwater()] routine returns the maximum
|
||
** value of [sqlite3_memory_used()] since the high-water mark
|
||
** was last reset. ^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.
|
||
**
|
||
** ^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.
|
||
*/
|
||
SQLITE_API sqlite3_int64 sqlite3_memory_used(void);
|
||
SQLITE_API sqlite3_int64 sqlite3_memory_highwater(int resetFlag);
|
||
|
||
/*
|
||
** CAPI3REF: Pseudo-Random Number Generator
|
||
**
|
||
** SQLite contains a high-quality pseudo-random number generator (PRNG) used to
|
||
** select random [ROWID | ROWIDs] when inserting new records into a table that
|
||
** already uses the largest possible [ROWID]. The PRNG is also used for
|
||
** the build-in random() and randomblob() SQL functions. This interface allows
|
||
** applications to access the same PRNG for other purposes.
|
||
**
|
||
** ^A call to this routine stores N bytes of randomness into buffer P.
|
||
**
|
||
** ^The first time this routine is invoked (either internally or by
|
||
** the application) the PRNG is seeded using randomness obtained
|
||
** from the xRandomness method of the default [sqlite3_vfs] object.
|
||
** ^On all subsequent invocations, the pseudo-randomness is generated
|
||
** internally and without recourse to the [sqlite3_vfs] xRandomness
|
||
** method.
|
||
*/
|
||
SQLITE_API void sqlite3_randomness(int N, void *P);
|
||
|
||
/*
|
||
** CAPI3REF: Compile-Time Authorization Callbacks
|
||
**
|
||
** ^This routine registers an authorizer callback with a particular
|
||
** [database connection], supplied in the first argument.
|
||
** ^The authorizer callback is invoked as SQL statements are being compiled
|
||
** by [sqlite3_prepare()] or its variants [sqlite3_prepare_v2()],
|
||
** [sqlite3_prepare16()] and [sqlite3_prepare16_v2()]. ^At various
|
||
** points during the compilation process, as logic is being created
|
||
** to perform various actions, the authorizer callback is invoked to
|
||
** see if those actions are allowed. ^The authorizer callback should
|
||
** return [SQLITE_OK] to allow the action, [SQLITE_IGNORE] to disallow the
|
||
** specific action but allow the SQL statement to continue to be
|
||
** compiled, or [SQLITE_DENY] to cause the entire SQL statement to be
|
||
** rejected with an error. ^If the authorizer callback returns
|
||
** any value other than [SQLITE_IGNORE], [SQLITE_OK], or [SQLITE_DENY]
|
||
** then the [sqlite3_prepare_v2()] or equivalent call that triggered
|
||
** the authorizer will fail with an error message.
|
||
**
|
||
** When the callback returns [SQLITE_OK], that means the operation
|
||
** requested is ok. ^When the callback returns [SQLITE_DENY], the
|
||
** [sqlite3_prepare_v2()] or equivalent call that triggered the
|
||
** authorizer will fail with an error message explaining that
|
||
** access is denied.
|
||
**
|
||
** ^The first parameter to the authorizer callback is a copy of the third
|
||
** parameter to the sqlite3_set_authorizer() interface. ^The second parameter
|
||
** to the callback is an integer [SQLITE_COPY | action code] that specifies
|
||
** the particular action to be authorized. ^The third through sixth parameters
|
||
** to the callback are zero-terminated strings that contain additional
|
||
** details about the action to be authorized.
|
||
**
|
||
** ^If the action code is [SQLITE_READ]
|
||
** and the callback returns [SQLITE_IGNORE] then the
|
||
** [prepared statement] statement is constructed to substitute
|
||
** a NULL value in place of the table column that would have
|
||
** been read if [SQLITE_OK] had been returned. The [SQLITE_IGNORE]
|
||
** return can be used to deny an untrusted user access to individual
|
||
** columns of a table.
|
||
** ^If the action code is [SQLITE_DELETE] and the callback returns
|
||
** [SQLITE_IGNORE] then the [DELETE] operation proceeds but the
|
||
** [truncate optimization] is disabled and all rows are deleted individually.
|
||
**
|
||
** An authorizer is used when [sqlite3_prepare | preparing]
|
||
** SQL statements from an untrusted source, to ensure that the SQL statements
|
||
** do not try to access data they are not allowed to see, or that they do not
|
||
** try to execute malicious statements that damage the database. For
|
||
** example, an application may allow a user to enter arbitrary
|
||
** SQL queries for evaluation by a database. But the application does
|
||
** not want the user to be able to make arbitrary changes to the
|
||
** database. An authorizer could then be put in place while the
|
||
** user-entered SQL is being [sqlite3_prepare | prepared] that
|
||
** disallows everything except [SELECT] statements.
|
||
**
|
||
** Applications that need to process SQL from untrusted sources
|
||
** might also consider lowering resource limits using [sqlite3_limit()]
|
||
** and limiting database size using the [max_page_count] [PRAGMA]
|
||
** in addition to using an authorizer.
|
||
**
|
||
** ^(Only a single authorizer can be in place on a database connection
|
||
** at a time. Each call to sqlite3_set_authorizer overrides the
|
||
** previous call.)^ ^Disable the authorizer by installing a NULL callback.
|
||
** The authorizer is disabled by default.
|
||
**
|
||
** The authorizer callback must not do anything that will modify
|
||
** the database connection that invoked the authorizer callback.
|
||
** Note that [sqlite3_prepare_v2()] and [sqlite3_step()] both modify their
|
||
** database connections for the meaning of "modify" in this paragraph.
|
||
**
|
||
** ^When [sqlite3_prepare_v2()] is used to prepare a statement, the
|
||
** statement might be re-prepared during [sqlite3_step()] due to a
|
||
** schema change. Hence, the application should ensure that the
|
||
** correct authorizer callback remains in place during the [sqlite3_step()].
|
||
**
|
||
** ^Note that the authorizer callback is invoked only during
|
||
** [sqlite3_prepare()] or its variants. Authorization is not
|
||
** performed during statement evaluation in [sqlite3_step()], unless
|
||
** as stated in the previous paragraph, sqlite3_step() invokes
|
||
** sqlite3_prepare_v2() to reprepare a statement after a schema change.
|
||
*/
|
||
SQLITE_API int sqlite3_set_authorizer(
|
||
sqlite3*,
|
||
int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
|
||
void *pUserData
|
||
);
|
||
|
||
/*
|
||
** CAPI3REF: Authorizer Return Codes
|
||
**
|
||
** The [sqlite3_set_authorizer | authorizer callback function] must
|
||
** return either [SQLITE_OK] or one of these two constants in order
|
||
** to signal SQLite whether or not the action is permitted. See the
|
||
** [sqlite3_set_authorizer | authorizer documentation] for additional
|
||
** information.
|
||
**
|
||
** Note that SQLITE_IGNORE is also used as a [SQLITE_ROLLBACK | return code]
|
||
** from the [sqlite3_vtab_on_conflict()] interface.
|
||
*/
|
||
#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 */
|
||
|
||
/*
|
||
** CAPI3REF: Authorizer Action Codes
|
||
**
|
||
** The [sqlite3_set_authorizer()] interface registers a callback function
|
||
** that is invoked to authorize certain SQL statement actions. The
|
||
** second parameter to the callback is an integer code that specifies
|
||
** what action is being authorized. These are the integer action codes that
|
||
** the authorizer callback may be passed.
|
||
**
|
||
** These action code values signify what kind of operation is to be
|
||
** authorized. The 3rd and 4th parameters to the authorization
|
||
** callback function will be parameters or NULL depending on which of these
|
||
** codes is used as the second parameter. ^(The 5th parameter to the
|
||
** authorizer callback is the name of the database ("main", "temp",
|
||
** etc.) if applicable.)^ ^The 6th parameter to the authorizer callback
|
||
** is 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.
|
||
*/
|
||
/******************************************* 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 /* Operation 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_SAVEPOINT 32 /* Operation Savepoint Name */
|
||
#define SQLITE_COPY 0 /* No longer used */
|
||
|
||
/*
|
||
** CAPI3REF: Tracing And Profiling Functions
|
||
**
|
||
** These routines register callback functions that can be used for
|
||
** tracing and profiling the execution of SQL statements.
|
||
**
|
||
** ^The callback function registered by sqlite3_trace() is invoked at
|
||
** various times when an SQL statement is being run by [sqlite3_step()].
|
||
** ^The sqlite3_trace() callback is invoked with a UTF-8 rendering of the
|
||
** SQL statement text as the statement first begins executing.
|
||
** ^(Additional sqlite3_trace() callbacks might occur
|
||
** as each triggered subprogram is entered. The callbacks for triggers
|
||
** contain a UTF-8 SQL comment that identifies the trigger.)^
|
||
**
|
||
** ^The callback function registered by sqlite3_profile() is invoked
|
||
** as each SQL statement finishes. ^The profile callback contains
|
||
** the original statement text and an estimate of wall-clock time
|
||
** of how long that statement took to run. ^The profile callback
|
||
** time is in units of nanoseconds, however the current implementation
|
||
** is only capable of millisecond resolution so the six least significant
|
||
** digits in the time are meaningless. Future versions of SQLite
|
||
** might provide greater resolution on the profiler callback. The
|
||
** sqlite3_profile() function is considered experimental and is
|
||
** subject to change in future versions of SQLite.
|
||
*/
|
||
SQLITE_API void *sqlite3_trace(sqlite3*, void(*xTrace)(void*,const char*), void*);
|
||
SQLITE_API SQLITE_EXPERIMENTAL void *sqlite3_profile(sqlite3*,
|
||
void(*xProfile)(void*,const char*,sqlite3_uint64), void*);
|
||
|
||
/*
|
||
** CAPI3REF: Query Progress Callbacks
|
||
**
|
||
** ^The sqlite3_progress_handler(D,N,X,P) interface causes the callback
|
||
** function X to be invoked periodically during long running calls to
|
||
** [sqlite3_exec()], [sqlite3_step()] and [sqlite3_get_table()] for
|
||
** database connection D. An example use for this
|
||
** interface is to keep a GUI updated during a large query.
|
||
**
|
||
** ^The parameter P is passed through as the only parameter to the
|
||
** callback function X. ^The parameter N is the number of
|
||
** [virtual machine instructions] that are evaluated between successive
|
||
** invocations of the callback X.
|
||
**
|
||
** ^Only a single progress handler may be defined at one time per
|
||
** [database connection]; setting a new progress handler cancels the
|
||
** old one. ^Setting parameter X to NULL disables the progress handler.
|
||
** ^The progress handler is also disabled by setting N to a value less
|
||
** than 1.
|
||
**
|
||
** ^If the progress callback returns non-zero, the operation is
|
||
** interrupted. This feature can be used to implement a
|
||
** "Cancel" button on a GUI progress dialog box.
|
||
**
|
||
** The progress handler callback must not do anything that will modify
|
||
** the database connection that invoked the progress handler.
|
||
** Note that [sqlite3_prepare_v2()] and [sqlite3_step()] both modify their
|
||
** database connections for the meaning of "modify" in this paragraph.
|
||
**
|
||
*/
|
||
SQLITE_API void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);
|
||
|
||
/*
|
||
** CAPI3REF: Opening A New Database Connection
|
||
**
|
||
** ^These routines open an SQLite database file as specified by the
|
||
** filename argument. ^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(). ^(A [database connection] handle is usually
|
||
** returned in *ppDb, even if an error occurs. The only exception is that
|
||
** if SQLite is unable to allocate memory to hold the [sqlite3] object,
|
||
** a NULL will be written into *ppDb instead of a pointer to the [sqlite3]
|
||
** object.)^ ^(If the database is opened (and/or created) successfully, then
|
||
** [SQLITE_OK] is returned. Otherwise an [error code] is returned.)^ ^The
|
||
** [sqlite3_errmsg()] or [sqlite3_errmsg16()] routines can be used to obtain
|
||
** an English language description of the error following a failure of any
|
||
** of the sqlite3_open() routines.
|
||
**
|
||
** ^The default encoding for the database will be UTF-8 if
|
||
** sqlite3_open() or sqlite3_open_v2() is called and
|
||
** UTF-16 in the native byte order if sqlite3_open16() is used.
|
||
**
|
||
** Whether or not an error occurs when it is opened, resources
|
||
** associated with the [database connection] handle should be released by
|
||
** passing it to [sqlite3_close()] when it is no longer required.
|
||
**
|
||
** The sqlite3_open_v2() interface works like sqlite3_open()
|
||
** except that it accepts two additional parameters for additional control
|
||
** over the new database connection. ^(The flags parameter to
|
||
** sqlite3_open_v2() can take one of
|
||
** the following three values, optionally combined with the
|
||
** [SQLITE_OPEN_NOMUTEX], [SQLITE_OPEN_FULLMUTEX], [SQLITE_OPEN_SHAREDCACHE],
|
||
** [SQLITE_OPEN_PRIVATECACHE], and/or [SQLITE_OPEN_URI] flags:)^
|
||
**
|
||
** <dl>
|
||
** ^(<dt>[SQLITE_OPEN_READONLY]</dt>
|
||
** <dd>The database is opened in read-only mode. If the database does not
|
||
** already exist, an error is returned.</dd>)^
|
||
**
|
||
** ^(<dt>[SQLITE_OPEN_READWRITE]</dt>
|
||
** <dd>The database is opened for reading and writing if possible, or reading
|
||
** only if the file is write protected by the operating system. In either
|
||
** case the database must already exist, otherwise an error is returned.</dd>)^
|
||
**
|
||
** ^(<dt>[SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE]</dt>
|
||
** <dd>The database is opened for reading and writing, and is created if
|
||
** it does not already exist. This is the behavior that is always used for
|
||
** sqlite3_open() and sqlite3_open16().</dd>)^
|
||
** </dl>
|
||
**
|
||
** If the 3rd parameter to sqlite3_open_v2() is not one of the
|
||
** combinations shown above optionally combined with other
|
||
** [SQLITE_OPEN_READONLY | SQLITE_OPEN_* bits]
|
||
** then the behavior is undefined.
|
||
**
|
||
** ^If the [SQLITE_OPEN_NOMUTEX] flag is set, then the database connection
|
||
** opens in the multi-thread [threading mode] as long as the single-thread
|
||
** mode has not been set at compile-time or start-time. ^If the
|
||
** [SQLITE_OPEN_FULLMUTEX] flag is set then the database connection opens
|
||
** in the serialized [threading mode] unless single-thread was
|
||
** previously selected at compile-time or start-time.
|
||
** ^The [SQLITE_OPEN_SHAREDCACHE] flag causes the database connection to be
|
||
** eligible to use [shared cache mode], regardless of whether or not shared
|
||
** cache is enabled using [sqlite3_enable_shared_cache()]. ^The
|
||
** [SQLITE_OPEN_PRIVATECACHE] flag causes the database connection to not
|
||
** participate in [shared cache mode] even if it is enabled.
|
||
**
|
||
** ^The fourth parameter to sqlite3_open_v2() is the name of the
|
||
** [sqlite3_vfs] object that defines the operating system interface that
|
||
** the new database connection should use. ^If the fourth parameter is
|
||
** a NULL pointer then the default [sqlite3_vfs] object is used.
|
||
**
|
||
** ^If the filename is ":memory:", then a private, temporary in-memory database
|
||
** is created for the connection. ^This in-memory database will vanish when
|
||
** the database connection is closed. Future versions of SQLite might
|
||
** make use of additional special filenames that begin with the ":" character.
|
||
** It is recommended that when a database filename actually does begin with
|
||
** a ":" character you should prefix the filename with a pathname such as
|
||
** "./" to avoid ambiguity.
|
||
**
|
||
** ^If the filename is an empty string, then a private, temporary
|
||
** on-disk database will be created. ^This private database will be
|
||
** automatically deleted as soon as the database connection is closed.
|
||
**
|
||
** [[URI filenames in sqlite3_open()]] <h3>URI Filenames</h3>
|
||
**
|
||
** ^If [URI filename] interpretation is enabled, and the filename argument
|
||
** begins with "file:", then the filename is interpreted as a URI. ^URI
|
||
** filename interpretation is enabled if the [SQLITE_OPEN_URI] flag is
|
||
** set in the fourth argument to sqlite3_open_v2(), or if it has
|
||
** been enabled globally using the [SQLITE_CONFIG_URI] option with the
|
||
** [sqlite3_config()] method or by the [SQLITE_USE_URI] compile-time option.
|
||
** As of SQLite version 3.7.7, URI filename interpretation is turned off
|
||
** by default, but future releases of SQLite might enable URI filename
|
||
** interpretation by default. See "[URI filenames]" for additional
|
||
** information.
|
||
**
|
||
** URI filenames are parsed according to RFC 3986. ^If the URI contains an
|
||
** authority, then it must be either an empty string or the string
|
||
** "localhost". ^If the authority is not an empty string or "localhost", an
|
||
** error is returned to the caller. ^The fragment component of a URI, if
|
||
** present, is ignored.
|
||
**
|
||
** ^SQLite uses the path component of the URI as the name of the disk file
|
||