1/* 2** 2001 September 15 3** 4** The author disclaims copyright to this source code. In place of 5** a legal notice, here is a blessing: 6** 7** May you do good and not evil. 8** May you find forgiveness for yourself and forgive others. 9** May you share freely, never taking more than you give. 10** 11************************************************************************* 12** This header file defines the interface that the SQLite library 13** presents to client programs. If a C-function, structure, datatype, 14** or constant definition does not appear in this file, then it is 15** not a published API of SQLite, is subject to change without 16** notice, and should not be referenced by programs that use SQLite. 17** 18** Some of the definitions that are in this file are marked as 19** "experimental". Experimental interfaces are normally new 20** features recently added to SQLite. We do not anticipate changes 21** to experimental interfaces but reserve to make minor changes if 22** experience from use "in the wild" suggest such changes are prudent. 23** 24** The official C-language API documentation for SQLite is derived 25** from comments in this file. This file is the authoritative source 26** on how SQLite interfaces are suppose to operate. 27** 28** The name of this file under configuration management is "sqlite.h.in". 29** The makefile makes some minor changes to this file (such as inserting 30** the version number) and changes its name to "sqlite3.h" as 31** part of the build process. 32** 33** @(#) $Id: sqlite.h.in,v 1.250 2007/08/30 16:23:19 drh Exp $ 34*/ 35#ifndef _SQLITE3_H_ 36#define _SQLITE3_H_ 37#include <stdarg.h> /* Needed for the definition of va_list */ 38 39/* 40** Make sure we can call this stuff from C++. 41*/ 42#ifdef __cplusplus 43extern "C" { 44#endif 45 46 47/* 48** Add the ability to override 'extern' 49*/ 50#ifndef SQLITE_EXTERN 51# define SQLITE_EXTERN extern 52#endif 53 54/* 55** Make sure these symbols where not defined by some previous header 56** file. 57*/ 58#ifdef SQLITE_VERSION 59# undef SQLITE_VERSION 60#endif 61#ifdef SQLITE_VERSION_NUMBER 62# undef SQLITE_VERSION_NUMBER 63#endif 64 65/* 66** CAPI3REF: Compile-Time Library Version Numbers 67** 68** The version of the SQLite library is contained in the sqlite3.h 69** header file in a #define named SQLITE_VERSION. The SQLITE_VERSION 70** macro resolves to a string constant. 71** 72** The format of the version string is "X.Y.Z", where 73** X is the major version number, Y is the minor version number and Z 74** is the release number. The X.Y.Z might be followed by "alpha" or "beta". 75** For example "3.1.1beta". 76** 77** The X value is always 3 in SQLite. The X value only changes when 78** backwards compatibility is broken and we intend to never break 79** backwards compatibility. The Y value only changes when 80** there are major feature enhancements that are forwards compatible 81** but not backwards compatible. The Z value is incremented with 82** each release but resets back to 0 when Y is incremented. 83** 84** The SQLITE_VERSION_NUMBER is an integer with the value 85** (X*1000000 + Y*1000 + Z). For example, for version "3.1.1beta", 86** SQLITE_VERSION_NUMBER is set to 3001001. To detect if they are using 87** version 3.1.1 or greater at compile time, programs may use the test 88** (SQLITE_VERSION_NUMBER>=3001001). 89** 90** See also: [sqlite3_libversion()] and [sqlite3_libversion_number()]. 91*/ 92#define SQLITE_VERSION "--VERS--" 93#define SQLITE_VERSION_NUMBER --VERSION-NUMBER-- 94 95/* 96** CAPI3REF: Run-Time Library Version Numbers 97** 98** These routines return values equivalent to the header constants 99** [SQLITE_VERSION] and [SQLITE_VERSION_NUMBER]. The values returned 100** by this routines should only be different from the header values 101** if you compile your program using an sqlite3.h header from a 102** different version of SQLite that the version of the library you 103** link against. 104** 105** The sqlite3_version[] string constant contains the text of the 106** [SQLITE_VERSION] string. The sqlite3_libversion() function returns 107** a poiner to the sqlite3_version[] string constant. The function 108** is provided for DLL users who can only access functions and not 109** constants within the DLL. 110*/ 111SQLITE_EXTERN const char sqlite3_version[]; 112const char *sqlite3_libversion(void); 113int sqlite3_libversion_number(void); 114 115/* 116** CAPI3REF: Database Connection Handle 117** 118** Each open SQLite database is represented by pointer to an instance of the 119** opaque structure named "sqlite3". It is useful to think of an sqlite3 120** pointer as an object. The [sqlite3_open()], [sqlite3_open16()], and 121** [sqlite3_open_v2()] interfaces are its constructors 122** and [sqlite3_close()] is its destructor. There are many other interfaces 123** (such as [sqlite3_prepare_v2()], [sqlite3_create_function()], and 124** [sqlite3_busy_timeout()] to name but three) that are methods on this 125** object. 126*/ 127typedef struct sqlite3 sqlite3; 128 129 130/* 131** CAPI3REF: 64-Bit Integer Types 132** 133** Some compilers do not support the "long long" datatype. So we have 134** to do compiler-specific typedefs for 64-bit signed and unsigned integers. 135** 136** Many SQLite interface functions require a 64-bit integer arguments. 137** Those interfaces are declared using this typedef. 138*/ 139#ifdef SQLITE_INT64_TYPE 140 typedef SQLITE_INT64_TYPE sqlite_int64; 141 typedef unsigned SQLITE_INT64_TYPE sqlite_uint64; 142#elif defined(_MSC_VER) || defined(__BORLANDC__) 143 typedef __int64 sqlite_int64; 144 typedef unsigned __int64 sqlite_uint64; 145#else 146 typedef long long int sqlite_int64; 147 typedef unsigned long long int sqlite_uint64; 148#endif 149typedef sqlite_int64 sqlite3_int64; 150typedef sqlite_uint64 sqlite3_uint64; 151 152/* 153** If compiling for a processor that lacks floating point support, 154** substitute integer for floating-point 155*/ 156#ifdef SQLITE_OMIT_FLOATING_POINT 157# define double sqlite3_int64 158#endif 159 160/* 161** CAPI3REF: Closing A Database Connection 162** 163** Call this function with a pointer to a structure that was previously 164** returned from [sqlite3_open()], [sqlite3_open16()], or 165** [sqlite3_open_v2()] and the corresponding database will by 166** closed. 167** 168** All SQL statements prepared using [sqlite3_prepare_v2()] or 169** [sqlite3_prepare16_v2()] must be destroyed using [sqlite3_finalize()] 170** before this routine is called. Otherwise, SQLITE_BUSY is returned and the 171** database connection remains open. 172** 173** Passing this routine a database connection that has already been 174** closed results in undefined behavior. If other interfaces that 175** reference the same database connection are pending (either in the 176** same thread or in different threads) when this routine is called, 177** then the behavior is undefined and is almost certainly undesirable. 178*/ 179int sqlite3_close(sqlite3 *); 180 181/* 182** The type for a callback function. 183** This is legacy and deprecated. It is included for historical 184** compatibility and is not documented. 185*/ 186typedef int (*sqlite3_callback)(void*,int,char**, char**); 187 188/* 189** CAPI3REF: One-Step Query Execution Interface 190** 191** This interface is used to do a one-time evaluatation of zero 192** or more SQL statements. UTF-8 text of the SQL statements to 193** be evaluted is passed in as the second parameter. The statements 194** are prepared one by one using [sqlite3_prepare()], evaluated 195** using [sqlite3_step()], then destroyed using [sqlite3_finalize()]. 196** 197** If one or more of the SQL statements are queries, then 198** the callback function specified by the 3rd parameter is 199** invoked once for each row of the query result. This callback 200** should normally return 0. If the callback returns a non-zero 201** value then the query is aborted, all subsequent SQL statements 202** are skipped and the sqlite3_exec() function returns the SQLITE_ABORT. 203** 204** The 4th parameter to this interface is an arbitrary pointer that is 205** passed through to the callback function as its first parameter. 206** 207** The 2nd parameter to the callback function is the number of 208** columns in the query result. The 3rd parameter to the callback 209** is an array of strings holding the values for each column 210** as extracted using [sqlite3_column_text()]. 211** The 4th parameter to the callback is an array of strings 212** obtained using [sqlite3_column_name()] and holding 213** the names of each column. 214** 215** The callback function may be NULL, even for queries. A NULL 216** callback is not an error. It just means that no callback 217** will be invoked. 218** 219** If an error occurs while parsing or evaluating the SQL (but 220** not while executing the callback) then an appropriate error 221** message is written into memory obtained from [sqlite3_malloc()] and 222** *errmsg is made to point to that message. The calling function 223** is responsible for freeing the memory that holds the error 224** message. Use [sqlite3_free()] for this. If errmsg==NULL, 225** then no error message is ever written. 226** 227** The return value is is SQLITE_OK if there are no errors and 228** some other [SQLITE_OK | return code] if there is an error. 229** The particular return value depends on the type of error. 230** 231*/ 232int sqlite3_exec( 233 sqlite3*, /* An open database */ 234 const char *sql, /* SQL to be evaluted */ 235 int (*callback)(void*,int,char**,char**), /* Callback function */ 236 void *, /* 1st argument to callback */ 237 char **errmsg /* Error msg written here */ 238); 239 240/* 241** CAPI3REF: Result Codes 242** KEYWORDS: SQLITE_OK 243** 244** Many SQLite functions return an integer result code from the set shown 245** above in order to indicates success or failure. 246** 247** The result codes above are the only ones returned by SQLite in its 248** default configuration. However, the [sqlite3_extended_result_codes()] 249** API can be used to set a database connectoin to return more detailed 250** result codes. 251** 252** See also: [SQLITE_IOERR_READ | extended result codes] 253** 254*/ 255#define SQLITE_OK 0 /* Successful result */ 256/* beginning-of-error-codes */ 257#define SQLITE_ERROR 1 /* SQL error or missing database */ 258#define SQLITE_INTERNAL 2 /* NOT USED. Internal logic error in SQLite */ 259#define SQLITE_PERM 3 /* Access permission denied */ 260#define SQLITE_ABORT 4 /* Callback routine requested an abort */ 261#define SQLITE_BUSY 5 /* The database file is locked */ 262#define SQLITE_LOCKED 6 /* A table in the database is locked */ 263#define SQLITE_NOMEM 7 /* A malloc() failed */ 264#define SQLITE_READONLY 8 /* Attempt to write a readonly database */ 265#define SQLITE_INTERRUPT 9 /* Operation terminated by sqlite3_interrupt()*/ 266#define SQLITE_IOERR 10 /* Some kind of disk I/O error occurred */ 267#define SQLITE_CORRUPT 11 /* The database disk image is malformed */ 268#define SQLITE_NOTFOUND 12 /* NOT USED. Table or record not found */ 269#define SQLITE_FULL 13 /* Insertion failed because database is full */ 270#define SQLITE_CANTOPEN 14 /* Unable to open the database file */ 271#define SQLITE_PROTOCOL 15 /* NOT USED. Database lock protocol error */ 272#define SQLITE_EMPTY 16 /* Database is empty */ 273#define SQLITE_SCHEMA 17 /* The database schema changed */ 274#define SQLITE_TOOBIG 18 /* String or BLOB exceeds size limit */ 275#define SQLITE_CONSTRAINT 19 /* Abort due to contraint violation */ 276#define SQLITE_MISMATCH 20 /* Data type mismatch */ 277#define SQLITE_MISUSE 21 /* Library used incorrectly */ 278#define SQLITE_NOLFS 22 /* Uses OS features not supported on host */ 279#define SQLITE_AUTH 23 /* Authorization denied */ 280#define SQLITE_FORMAT 24 /* Auxiliary database format error */ 281#define SQLITE_RANGE 25 /* 2nd parameter to sqlite3_bind out of range */ 282#define SQLITE_NOTADB 26 /* File opened that is not a database file */ 283#define SQLITE_ROW 100 /* sqlite3_step() has another row ready */ 284#define SQLITE_DONE 101 /* sqlite3_step() has finished executing */ 285/* end-of-error-codes */ 286 287/* 288** CAPI3REF: Extended Result Codes 289** 290** In its default configuration, SQLite API routines return one of 26 integer 291** result codes described at result-codes. However, experience has shown that 292** many of these result codes are too course-grained. They do not provide as 293** much information about problems as users might like. In an effort to 294** address this, newer versions of SQLite (version 3.3.8 and later) include 295** support for additional result codes that provide more detailed information 296** about errors. The extended result codes are enabled (or disabled) for 297** each database 298** connection using the [sqlite3_extended_result_codes()] API. 299** 300** Some of the available extended result codes are listed above. 301** We expect the number of extended result codes will be expand 302** over time. Software that uses extended result codes should expect 303** to see new result codes in future releases of SQLite. 304** 305** The symbolic name for an extended result code always contains a related 306** primary result code as a prefix. Primary result codes contain a single 307** "_" character. Extended result codes contain two or more "_" characters. 308** The numeric value of an extended result code can be converted to its 309** corresponding primary result code by masking off the lower 8 bytes. 310** 311** The SQLITE_OK result code will never be extended. It will always 312** be exactly zero. 313*/ 314#define SQLITE_IOERR_READ (SQLITE_IOERR | (1<<8)) 315#define SQLITE_IOERR_SHORT_READ (SQLITE_IOERR | (2<<8)) 316#define SQLITE_IOERR_WRITE (SQLITE_IOERR | (3<<8)) 317#define SQLITE_IOERR_FSYNC (SQLITE_IOERR | (4<<8)) 318#define SQLITE_IOERR_DIR_FSYNC (SQLITE_IOERR | (5<<8)) 319#define SQLITE_IOERR_TRUNCATE (SQLITE_IOERR | (6<<8)) 320#define SQLITE_IOERR_FSTAT (SQLITE_IOERR | (7<<8)) 321#define SQLITE_IOERR_UNLOCK (SQLITE_IOERR | (8<<8)) 322#define SQLITE_IOERR_RDLOCK (SQLITE_IOERR | (9<<8)) 323#define SQLITE_IOERR_DELETE (SQLITE_IOERR | (10<<8)) 324#define SQLITE_IOERR_BLOCKED (SQLITE_IOERR | (11<<8)) 325 326/* 327** CAPI3REF: Flags For File Open Operations 328** 329** Combination of the following bit values are used as the 330** third argument to the [sqlite3_open_v2()] interface and 331** as fourth argument to the xOpen method of the 332** [sqlite3_vfs] object. 333** 334*/ 335#define SQLITE_OPEN_READONLY 0x00000001 336#define SQLITE_OPEN_READWRITE 0x00000002 337#define SQLITE_OPEN_CREATE 0x00000004 338#define SQLITE_OPEN_DELETEONCLOSE 0x00000008 339#define SQLITE_OPEN_EXCLUSIVE 0x00000010 340#define SQLITE_OPEN_MAIN_DB 0x00000100 341#define SQLITE_OPEN_TEMP_DB 0x00000200 342#define SQLITE_OPEN_MAIN_JOURNAL 0x00000400 343#define SQLITE_OPEN_TEMP_JOURNAL 0x00000800 344#define SQLITE_OPEN_SUBJOURNAL 0x00001000 345#define SQLITE_OPEN_MASTER_JOURNAL 0x00002000 346 347/* 348** CAPI3REF: Device Characteristics 349** 350** The xDeviceCapabilities method of the [sqlite3_io_methods] 351** object returns an integer which is a vector of the following 352** bit values expressing I/O characteristics of the mass storage 353** device that holds the file that the [sqlite3_io_methods] 354** refers to. 355** 356** The SQLITE_IOCAP_ATOMIC property means that all writes of 357** any size are atomic. The SQLITE_IOCAP_ATOMICnnn values 358** mean that writes of blocks that are nnn bytes in size and 359** are aligned to an address which is an integer multiple of 360** nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means 361** that when data is appended to a file, the data is appended 362** first then the size of the file is extended, never the other 363** way around. The SQLITE_IOCAP_SEQUENTIAL property means that 364** information is written to disk in the same order as calls 365** to xWrite(). 366*/ 367#define SQLITE_IOCAP_ATOMIC 0x00000001 368#define SQLITE_IOCAP_ATOMIC512 0x00000002 369#define SQLITE_IOCAP_ATOMIC1K 0x00000004 370#define SQLITE_IOCAP_ATOMIC2K 0x00000008 371#define SQLITE_IOCAP_ATOMIC4K 0x00000010 372#define SQLITE_IOCAP_ATOMIC8K 0x00000020 373#define SQLITE_IOCAP_ATOMIC16K 0x00000040 374#define SQLITE_IOCAP_ATOMIC32K 0x00000080 375#define SQLITE_IOCAP_ATOMIC64K 0x00000100 376#define SQLITE_IOCAP_SAFE_APPEND 0x00000200 377#define SQLITE_IOCAP_SEQUENTIAL 0x00000400 378 379/* 380** CAPI3REF: File Locking Levels 381** 382** SQLite uses one of the following integer values as the second 383** argument to calls it makes to the xLock() and xUnlock() methods 384** of an [sqlite3_io_methods] object. 385*/ 386#define SQLITE_LOCK_NONE 0 387#define SQLITE_LOCK_SHARED 1 388#define SQLITE_LOCK_RESERVED 2 389#define SQLITE_LOCK_PENDING 3 390#define SQLITE_LOCK_EXCLUSIVE 4 391 392/* 393** CAPI3REF: Synchronization Type Flags 394** 395** When SQLite invokes the xSync() method of an [sqlite3_io_methods] 396** object it uses a combination of the following integer values as 397** the second argument. 398** 399** When the SQLITE_SYNC_DATAONLY flag is used, it means that the 400** sync operation only needs to flush data to mass storage. Inode 401** information need not be flushed. The SQLITE_SYNC_NORMAL means 402** to use normal fsync() semantics. The SQLITE_SYNC_FULL flag means 403** to use Mac OS-X style fullsync instead of fsync(). 404*/ 405#define SQLITE_SYNC_NORMAL 0x00002 406#define SQLITE_SYNC_FULL 0x00003 407#define SQLITE_SYNC_DATAONLY 0x00010 408 409 410/* 411** CAPI3REF: OS Interface Open File Handle 412** 413** An [sqlite3_file] object represents an open file in the OS 414** interface layer. Individual OS interface implementations will 415** want to subclass this object by appending additional fields 416** of their own use. The pMethods entry is a pointer to an 417** [sqlite3_io_methods] object that defines methods for performing 418** I/O operations on the open file. 419*/ 420typedef struct sqlite3_file sqlite3_file; 421struct sqlite3_file { 422 const struct sqlite3_io_methods *pMethods; /* Methods for an open file */ 423}; 424 425/* 426** CAPI3REF: OS Interface File Virtual Methods Object 427** 428** Every open file in the [sqlite3_vfs] xOpen method contains a pointer to 429** an instance of the following object. This object defines the 430** methods used to perform various operations against the open file. 431** 432** The flags argument to xSync may be one of SQLITE_SYNC_NORMAL or 433** SQLITE_SYNC_FULL. The first choice means that data is not 434** necessarily synced to disk completely, only that all writes that 435** occur before the sync complete before any writes that occur after the 436** sync. The second flag is the normal fsync(). The third flag is a 437** OS-X style fullsync. The SQLITE_SYNC_DATA flag may be ORed in to 438** indicate that only the data of the file and not its inode needs to be 439** synced. 440** 441** The integer values to xLock() and xUnlock() are one of 442** SQLITE_LOCK_NONE, SQLITE_LOCK_READ, SQLITE_LOCK_RESERVED, 443** SQLITE_LOCK_PENDING, or SQLITE_LOCK_EXCLUSIVE. xLock() 444** increases the lock. xUnlock() decreases the lock. 445** The xCheckReservedLock() method looks 446** to see if any database connection, either in this 447** process or in some other process, is holding an RESERVED, 448** PENDING, or EXCLUSIVE lock on the file. It returns true 449** if such a lock exists and false if not. 450** 451** xBreakLock() attempts to break a lock held by another process. 452** This can be used to remove a stale dot-file lock, for example. 453** It returns 0 on success and non-zero for a failure. 454** 455** The xSectorSize() method returns the sector size of the 456** device that underlies the file. The sector size is the 457** minimum write that can be performed without disturbing 458** other bytes in the file. The xDeviceCharacteristics() 459** method returns a bit vector describing behaviors of the 460** underlying device: 461** 462** <ul> 463** <li> SQLITE_IOCAP_ATOMIC 464** <li> SQLITE_IOCAP_ATOMIC512 465** <li> SQLITE_IOCAP_ATOMIC1K 466** <li> SQLITE_IOCAP_ATOMIC2K 467** <li> SQLITE_IOCAP_ATOMIC4K 468** <li> SQLITE_IOCAP_ATOMIC8K 469** <li> SQLITE_IOCAP_ATOMIC16K 470** <li> SQLITE_IOCAP_ATOMIC32K 471** <li> SQLITE_IOCAP_ATOMIC64K 472** <li> SQLITE_IOCAP_SAFE_APPEND 473** <li> SQLITE_IOCAP_SEQUENTIAL 474** </ul> 475** 476** The SQLITE_IOCAP_ATOMIC property means that all writes of 477** any size are atomic. The SQLITE_IOCAP_ATOMICnnn values 478** mean that writes of blocks that are nnn bytes in size and 479** are aligned to an address which is an integer multiple of 480** nnn are atomic. The SQLITE_IOCAP_SAFE_APPEND value means 481** that when data is appended to a file, the data is appended 482** first then the size of the file is extended, never the other 483** way around. The SQLITE_IOCAP_SEQUENTIAL property means that 484** information is written to disk in the same order as calls 485** to xWrite(). 486*/ 487typedef struct sqlite3_io_methods sqlite3_io_methods; 488struct sqlite3_io_methods { 489 int iVersion; 490 int (*xClose)(sqlite3_file*); 491 int (*xRead)(sqlite3_file*, void*, int iAmt, sqlite_int64 iOfst); 492 int (*xWrite)(sqlite3_file*, const void*, int iAmt, sqlite_int64 iOfst); 493 int (*xTruncate)(sqlite3_file*, sqlite_int64 size); 494 int (*xSync)(sqlite3_file*, int flags); 495 int (*xFileSize)(sqlite3_file*, sqlite_int64 *pSize); 496 int (*xLock)(sqlite3_file*, int); 497 int (*xUnlock)(sqlite3_file*, int); 498 int (*xCheckReservedLock)(sqlite3_file*); 499 int (*xBreakLock)(sqlite3_file*); 500 int (*xLockState)(sqlite3_file *); 501 int (*xSectorSize)(sqlite3_file*); 502 int (*xDeviceCharacteristics)(sqlite3_file*); 503 /* Additional methods may be added in future releases */ 504}; 505 506/* 507** CAPI3REF: Mutex Handle 508** 509** The mutex module within SQLite defines [sqlite3_mutex] to be an 510** abstract type for a mutex object. The SQLite core never looks 511** at the internal representation of an [sqlite3_mutex]. It only 512** deals with pointers to the [sqlite3_mutex] object. 513** 514** Mutexes are created using [sqlite3_mutex_alloc()]. 515*/ 516typedef struct sqlite3_mutex sqlite3_mutex; 517 518/* 519** CAPI3REF: OS Interface Object 520** 521** An instance of this object defines the interface between the 522** SQLite core and the underlying operating system. The "vfs" 523** in the name of the object stands for "virtual file system". 524** 525** The iVersion field is initially 1 but may be larger for future 526** versions of SQLite. Additional fields may be appended to this 527** object when the iVersion value is increased. 528** 529** The szOsFile field is the size of the subclassed sqlite3_file 530** structure used by this VFS. mxPathname is the maximum length of 531** a pathname in this VFS. 532** 533** Registered vfs modules are kept on a linked list formed by 534** the pNext pointer. The [sqlite3_register_vfs()] 535** and [sqlite3_unregister_vfs()] interfaces manage this list 536** in a thread-safe way. The [sqlite3_find_vfs()] interface 537** searches the list. 538** 539** The pNext field is the only fields in the sqlite3_vfs 540** structure that SQLite will ever modify. SQLite will only access 541** or modify this field while holding a particular static mutex. 542** The application should never modify anything within the sqlite3_vfs 543** object once the object has been registered. 544** 545** The zName field holds the name of the VFS module. The name must 546** be unique across all VFS modules. 547** 548** SQLite will guarantee that the zFilename string passed to 549** xOpen() is a full pathname as generated by xFullPathname() and 550** that the string will be valid and unchanged until xClose() is 551** called. So the [sqlite3_file] can store a pointer to the 552** filename if it needs to remember the filename for some reason. 553** 554** The flags argument to xOpen() is a copy of the flags argument 555** to sqlite3_open_v2(). If sqlite3_open() or sqlite3_open16() 556** is used, then flags is SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE. 557** If xOpen() opens a file read-only then it sets *pOutFlags to 558** include SQLITE_OPEN_READONLY. Other bits in *pOutFlags may be 559** set. 560** 561** SQLite will also add one of the following flags to the xOpen() 562** call, depending on the object being opened: 563** 564** <ul> 565** <li> [SQLITE_OPEN_MAIN_DB] 566** <li> [SQLITE_OPEN_MAIN_JOURNAL] 567** <li> [SQLITE_OPEN_TEMP_DB] 568** <li> [SQLITE_OPEN_TEMP_JOURNAL] 569** <li> [SQLITE_OPEN_SUBJOURNAL] 570** <li> [SQLITE_OPEN_MASTER_JOURNAL] 571** </ul> 572** 573** The file I/O implementation can use the object type flags to 574** changes the way it deals with files. For example, an application 575** that does not care about crash recovery or rollback, might make 576** the open of a journal file a no-op. Writes to this journal are 577** also a no-op. Any attempt to read the journal return SQLITE_IOERR. 578** Or the implementation might recognize the a database file will 579** be doing page-aligned sector reads and writes in a random order 580** and set up its I/O subsystem accordingly. 581** 582** SQLite might also add one of the following flags to the xOpen 583** method: 584** 585** <ul> 586** <li> [SQLITE_OPEN_DELETEONCLOSE] 587** <li> [SQLITE_OPEN_EXCLUSIVE] 588** </ul> 589** 590** The [SQLITE_OPEN_DELETEONCLOSE] flag means the file should be 591** deleted when it is closed. This will always be set for TEMP 592** databases and journals and for subjournals. The 593** [SQLITE_OPEN_EXCLUSIVE] flag means the file should be opened 594** for exclusive access. This flag is set for all files except 595** for the main database file. 596** 597** Space to hold the [sqlite3_file] structure passed as the third 598** argument to xOpen is allocated by caller (the SQLite core). 599** szOsFile bytes are allocated for this object. The xOpen method 600** fills in the allocated space. 601** 602** The flags argument to xAccess() may be 0 (to test for the 603** existance of a file) or SQLITE_ACCESS_READWRITE to test to see 604** if a file is readable and writable, or SQLITE_ACCESS_READONLY 605** to test to see if a file is read-only. The file can be a 606** directory. 607** 608** SQLite will always allocate at least mxPathname+1 byte for 609** the output buffers for xGetTempName and xFullPathname. 610** 611** The xRandomness(), xSleep(), and xCurrentTime() interfaces 612** are not strictly a part of the filesystem, but they are 613** included in the VFS structure for completeness. 614** The xRandomness() function attempts to return nBytes bytes 615** of good-quality randomness into zOut. The return value is 616** the actual number of bytes of randomness generated. The 617** xSleep() method cause the calling thread to sleep for at 618** least the number of microseconds given. The xCurrentTime() 619** method returns a Julian Day Number for the current date and 620** time. 621*/ 622typedef struct sqlite3_vfs sqlite3_vfs; 623struct sqlite3_vfs { 624 int iVersion; /* Structure version number */ 625 int szOsFile; /* Size of subclassed sqlite3_file */ 626 int mxPathname; /* Maximum file pathname length */ 627 sqlite3_vfs *pNext; /* Next registered VFS */ 628 const char *zName; /* Name of this virtual file system */ 629 void *pAppData; /* Pointer to application-specific data */ 630 int (*xOpen)(sqlite3_vfs*, const char *zName, sqlite3_file*, 631 int flags, int *pOutFlags); 632 int (*xDelete)(sqlite3_vfs*, const char *zName, int syncDir); 633 int (*xAccess)(sqlite3_vfs*, const char *zName, int flags); 634 int (*xGetTempName)(sqlite3_vfs*, char *zOut); 635 int (*xFullPathname)(sqlite3_vfs*, const char *zName, char *zOut); 636 void *(*xDlOpen)(sqlite3_vfs*, const char *zFilename); 637 void (*xDlError)(sqlite3_vfs*, int nByte, char *zErrMsg); 638 void *(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol); 639 void (*xDlClose)(sqlite3_vfs*, void*); 640 int (*xRandomness)(sqlite3_vfs*, int nByte, char *zOut); 641 int (*xSleep)(sqlite3_vfs*, int microseconds); 642 int (*xCurrentTime)(sqlite3_vfs*, double*); 643 /* New fields may be appended in figure versions. The iVersion 644 ** value will increment whenever this happens. */ 645}; 646 647/* 648** CAPI3REF: Flags for the xAccess VFS method 649** 650** These integer constants can be used as the third parameter to 651** the xAccess method of an [sqlite3_vfs] object. They determine 652** the kind of what kind of permissions the xAccess method is 653** looking for. With SQLITE_ACCESS_EXISTS, the xAccess method 654** simply checks to see if the file exists. With SQLITE_ACCESS_READWRITE, 655** the xAccess method checks to see if the file is both readable 656** and writable. With SQLITE_ACCESS_READ the xAccess method 657** checks to see if the file is readable. 658*/ 659#define SQLITE_ACCESS_EXISTS 0 660#define SQLITE_ACCESS_READWRITE 1 661#define SQLITE_ACCESS_READ 2 662 663/* 664** CAPI3REF: Enable Or Disable Extended Result Codes 665** 666** This routine enables or disables the 667** [SQLITE_IOERR_READ | extended result codes] feature. 668** By default, SQLite API routines return one of only 26 integer 669** [SQLITE_OK | result codes]. When extended result codes 670** are enabled by this routine, the repetoire of result codes can be 671** much larger and can (hopefully) provide more detailed information 672** about the cause of an error. 673** 674** The second argument is a boolean value that turns extended result 675** codes on and off. Extended result codes are off by default for 676** backwards compatibility with older versions of SQLite. 677*/ 678int sqlite3_extended_result_codes(sqlite3*, int onoff); 679 680/* 681** CAPI3REF: Last Insert Rowid 682** 683** Each entry in an SQLite table has a unique 64-bit signed integer key 684** called the "rowid". The rowid is always available as an undeclared 685** column named ROWID, OID, or _ROWID_. If the table has a column of 686** type INTEGER PRIMARY KEY then that column is another an alias for the 687** rowid. 688** 689** This routine returns the rowid of the most recent INSERT into 690** the database from the database connection given in the first 691** argument. If no inserts have ever occurred on this database 692** connection, zero is returned. 693** 694** If an INSERT occurs within a trigger, then the rowid of the 695** inserted row is returned by this routine as long as the trigger 696** is running. But once the trigger terminates, the value returned 697** by this routine reverts to the last value inserted before the 698** trigger fired. 699** 700** If another thread does a new insert on the same database connection 701** while this routine is running and thus changes the last insert rowid, 702** then the return value of this routine is undefined. 703*/ 704sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*); 705 706/* 707** CAPI3REF: Count The Number Of Rows Modified 708** 709** This function returns the number of database rows that were changed 710** (or inserted or deleted) by the most recent SQL statement. Only 711** changes that are directly specified by the INSERT, UPDATE, or 712** DELETE statement are counted. Auxiliary changes caused by 713** triggers are not counted. Use the [sqlite3_total_changes()] function 714** to find the total number of changes including changes caused by triggers. 715** 716** Within the body of a trigger, the sqlite3_changes() interface can be 717** called to find the number of 718** changes in the most recently completed INSERT, UPDATE, or DELETE 719** statement within the body of the trigger. 720** 721** All changes are counted, even if they were later undone by a 722** ROLLBACK or ABORT. Except, changes associated with creating and 723** dropping tables are not counted. 724** 725** If a callback invokes [sqlite3_exec()] or [sqlite3_step()] recursively, 726** then the changes in the inner, recursive call are counted together 727** with the changes in the outer call. 728** 729** SQLite implements the command "DELETE FROM table" without a WHERE clause 730** by dropping and recreating the table. (This is much faster than going 731** through and deleting individual elements from the table.) Because of 732** this optimization, the change count for "DELETE FROM table" will be 733** zero regardless of the number of elements that were originally in the 734** table. To get an accurate count of the number of rows deleted, use 735** "DELETE FROM table WHERE 1" instead. 736** 737** If another thread makes changes on the same database connection 738** while this routine is running then the return value of this routine 739** is undefined. 740*/ 741int sqlite3_changes(sqlite3*); 742 743/* 744** CAPI3REF: Total Number Of Rows Modified 745*** 746** This function returns the number of database rows that have been 747** modified by INSERT, UPDATE or DELETE statements since the database handle 748** was opened. This includes UPDATE, INSERT and DELETE statements executed 749** as part of trigger programs. All changes are counted as soon as the 750** statement that makes them is completed (when the statement handle is 751** passed to [sqlite3_reset()] or [sqlite3_finalise()]). 752** 753** See also the [sqlite3_change()] interface. 754** 755** SQLite implements the command "DELETE FROM table" without a WHERE clause 756** by dropping and recreating the table. (This is much faster than going 757** through and deleting individual elements form the table.) Because of 758** this optimization, the change count for "DELETE FROM table" will be 759** zero regardless of the number of elements that were originally in the 760** table. To get an accurate count of the number of rows deleted, use 761** "DELETE FROM table WHERE 1" instead. 762** 763** If another thread makes changes on the same database connection 764** while this routine is running then the return value of this routine 765** is undefined. 766*/ 767int sqlite3_total_changes(sqlite3*); 768 769/* 770** CAPI3REF: Interrupt A Long-Running Query 771** 772** This function causes any pending database operation to abort and 773** return at its earliest opportunity. This routine is typically 774** called in response to a user action such as pressing "Cancel" 775** or Ctrl-C where the user wants a long query operation to halt 776** immediately. 777** 778** It is safe to call this routine from a thread different from the 779** thread that is currently running the database operation. But it 780** is not safe to call this routine with a database connection that 781** is closed or might close before sqlite3_interrupt() returns. 782** 783** The SQL operation that is interrupted will return [SQLITE_INTERRUPT]. 784** If an interrupted operation was an update that is inside an 785** explicit transaction, then the entire transaction will be rolled 786** back automatically. 787*/ 788void sqlite3_interrupt(sqlite3*); 789 790/* 791** CAPI3REF: Determine If An SQL Statement Is Complete 792** 793** These functions return true if the given input string comprises 794** one or more complete SQL statements. For the sqlite3_complete() call, 795** the parameter must be a nul-terminated UTF-8 string. For 796** sqlite3_complete16(), a nul-terminated machine byte order UTF-16 string 797** is required. 798** 799** These routines are useful for command-line input to determine if the 800** currently entered text forms one or more complete SQL statements or 801** if additional input is needed before sending the statements into 802** SQLite for parsing. The algorithm is simple. If the 803** last token other than spaces and comments is a semicolon, then return 804** true. Actually, the algorithm is a little more complicated than that 805** in order to deal with triggers, but the basic idea is the same: the 806** statement is not complete unless it ends in a semicolon. 807*/ 808int sqlite3_complete(const char *sql); 809int sqlite3_complete16(const void *sql); 810 811/* 812** CAPI3REF: Register A Callback To Handle SQLITE_BUSY Errors 813** 814** This routine identifies a callback function that might be invoked 815** whenever an attempt is made to open a database table 816** that another thread or process has locked. 817** If the busy callback is NULL, then [SQLITE_BUSY] 818** (or sometimes [SQLITE_IOERR_BLOCKED]) 819** is returned immediately upon encountering the lock. 820** If the busy callback is not NULL, then the 821** callback will be invoked with two arguments. The 822** first argument to the handler is a copy of the void* pointer which 823** is the third argument to this routine. The second argument to 824** the handler is the number of times that the busy handler has 825** been invoked for this locking event. If the 826** busy callback returns 0, then no additional attempts are made to 827** access the database and [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED] is returned. 828** If the callback returns non-zero, then another attempt is made to open the 829** database for reading and the cycle repeats. 830** 831** The presence of a busy handler does not guarantee that 832** it will be invoked when there is lock contention. 833** If SQLite determines that invoking the busy handler could result in 834** a deadlock, it will return [SQLITE_BUSY] instead. 835** Consider a scenario where one process is holding a read lock that 836** it is trying to promote to a reserved lock and 837** a second process is holding a reserved lock that it is trying 838** to promote to an exclusive lock. The first process cannot proceed 839** because it is blocked by the second and the second process cannot 840** proceed because it is blocked by the first. If both processes 841** invoke the busy handlers, neither will make any progress. Therefore, 842** SQLite returns [SQLITE_BUSY] for the first process, hoping that this 843** will induce the first process to release its read lock and allow 844** the second process to proceed. 845** 846** The default busy callback is NULL. 847** 848** The [SQLITE_BUSY] error is converted to [SQLITE_IOERR_BLOCKED] when 849** SQLite is in the middle of a large transaction where all the 850** changes will not fit into the in-memory cache. SQLite will 851** already hold a RESERVED lock on the database file, but it needs 852** to promote this lock to EXCLUSIVE so that it can spill cache 853** pages into the database file without harm to concurrent 854** readers. If it is unable to promote the lock, then the in-memory 855** cache will be left in an inconsistent state and so the error 856** code is promoted from the relatively benign [SQLITE_BUSY] to 857** the more severe [SQLITE_IOERR_BLOCKED]. This error code promotion 858** forces an automatic rollback of the changes. See the 859** <a href="http://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError"> 860** CorruptionFollowingBusyError</a> wiki page for a discussion of why 861** this is important. 862** 863** Sqlite is re-entrant, so the busy handler may start a new query. 864** (It is not clear why anyone would every want to do this, but it 865** is allowed, in theory.) But the busy handler may not close the 866** database. Closing the database from a busy handler will delete 867** data structures out from under the executing query and will 868** probably result in a segmentation fault or other runtime error. 869** 870** There can only be a single busy handler defined for each database 871** connection. Setting a new busy handler clears any previous one. 872** Note that calling [sqlite3_busy_timeout()] will also set or clear 873** the busy handler. 874** 875** When operating in [sqlite3_enable_shared_cache | shared cache mode], 876** only a single busy handler can be defined for each database file. 877** So if two database connections share a single cache, then changing 878** the busy handler on one connection will also change the busy 879** handler in the other connection. The busy handler is invoked 880** in the thread that was running when the SQLITE_BUSY was hit. 881*/ 882int sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*); 883 884/* 885** CAPI3REF: Set A Busy Timeout 886** 887** This routine sets a busy handler that sleeps for a while when a 888** table is locked. The handler will sleep multiple times until 889** at least "ms" milliseconds of sleeping have been done. After 890** "ms" milliseconds of sleeping, the handler returns 0 which 891** causes [sqlite3_step()] to return [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED]. 892** 893** Calling this routine with an argument less than or equal to zero 894** turns off all busy handlers. 895** 896** There can only be a single busy handler for a particular database 897** connection. If another busy handler was defined 898** (using [sqlite3_busy_handler()]) prior to calling 899** this routine, that other busy handler is cleared. 900*/ 901int sqlite3_busy_timeout(sqlite3*, int ms); 902 903/* 904** CAPI3REF: Convenience Routines For Running Queries 905** 906** This next routine is a convenience wrapper around [sqlite3_exec()]. 907** Instead of invoking a user-supplied callback for each row of the 908** result, this routine remembers each row of the result in memory 909** obtained from [sqlite3_malloc()], then returns all of the result after the 910** query has finished. 911** 912** As an example, suppose the query result where this table: 913** 914** <blockquote><pre> 915** Name | Age 916** ----------------------- 917** Alice | 43 918** Bob | 28 919** Cindy | 21 920** </pre></blockquote> 921** 922** If the 3rd argument were &azResult then after the function returns 923** azResult will contain the following data: 924** 925** <blockquote><pre> 926** azResult[0] = "Name"; 927** azResult[1] = "Age"; 928** azResult[2] = "Alice"; 929** azResult[3] = "43"; 930** azResult[4] = "Bob"; 931** azResult[5] = "28"; 932** azResult[6] = "Cindy"; 933** azResult[7] = "21"; 934** </pre></blockquote> 935** 936** Notice that there is an extra row of data containing the column 937** headers. But the *nrow return value is still 3. *ncolumn is 938** set to 2. In general, the number of values inserted into azResult 939** will be ((*nrow) + 1)*(*ncolumn). 940** 941** After the calling function has finished using the result, it should 942** pass the result data pointer to sqlite3_free_table() in order to 943** release the memory that was malloc-ed. Because of the way the 944** [sqlite3_malloc()] happens, the calling function must not try to call 945** [sqlite3_free()] directly. Only [sqlite3_free_table()] is able to release 946** the memory properly and safely. 947** 948** The return value of this routine is the same as from [sqlite3_exec()]. 949*/ 950int sqlite3_get_table( 951 sqlite3*, /* An open database */ 952 const char *sql, /* SQL to be executed */ 953 char ***resultp, /* Result written to a char *[] that this points to */ 954 int *nrow, /* Number of result rows written here */ 955 int *ncolumn, /* Number of result columns written here */ 956 char **errmsg /* Error msg written here */ 957); 958void sqlite3_free_table(char **result); 959 960/* 961** CAPI3REF: Formatted String Printing Functions 962** 963** These routines are workalikes of the "printf()" family of functions 964** from the standard C library. 965** 966** The sqlite3_mprintf() and sqlite3_vmprintf() routines write their 967** results into memory obtained from [sqlite3_malloc()]. 968** The strings returned by these two routines should be 969** released by [sqlite3_free()]. Both routines return a 970** NULL pointer if [sqlite3_malloc()] is unable to allocate enough 971** memory to hold the resulting string. 972** 973** In sqlite3_snprintf() routine is similar to "snprintf()" from 974** the standard C library. The result is written into the 975** buffer supplied as the second parameter whose size is given by 976** the first parameter. Note that the order of the 977** first two parameters is reversed from snprintf(). This is an 978** historical accident that cannot be fixed without breaking 979** backwards compatibility. Note also that sqlite3_snprintf() 980** returns a pointer to its buffer instead of the number of 981** characters actually written into the buffer. We admit that 982** the number of characters written would be a more useful return 983** value but we cannot change the implementation of sqlite3_snprintf() 984** now without breaking compatibility. 985** 986** As long as the buffer size is greater than zero, sqlite3_snprintf() 987** guarantees that the buffer is always zero-terminated. The first 988** parameter "n" is the total size of the buffer, including space for 989** the zero terminator. So the longest string that can be completely 990** written will be n-1 characters. 991** 992** These routines all implement some additional formatting 993** options that are useful for constructing SQL statements. 994** All of the usual printf formatting options apply. In addition, there 995** is are "%q", "%Q", and "%z" options. 996** 997** The %q option works like %s in that it substitutes a null-terminated 998** string from the argument list. But %q also doubles every '\'' character. 999** %q is designed for use inside a string literal. By doubling each '\'' 1000** character it escapes that character and allows it to be inserted into 1001** the string. 1002** 1003** For example, so some string variable contains text as follows: 1004** 1005** <blockquote><pre> 1006** char *zText = "It's a happy day!"; 1007** </pre></blockquote> 1008** 1009** One can use this text in an SQL statement as follows: 1010** 1011** <blockquote><pre> 1012** char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES('%q')", zText); 1013** sqlite3_exec(db, zSQL, 0, 0, 0); 1014** sqlite3_free(zSQL); 1015** </pre></blockquote> 1016** 1017** Because the %q format string is used, the '\'' character in zText 1018** is escaped and the SQL generated is as follows: 1019** 1020** <blockquote><pre> 1021** INSERT INTO table1 VALUES('It''s a happy day!') 1022** </pre></blockquote> 1023** 1024** This is correct. Had we used %s instead of %q, the generated SQL 1025** would have looked like this: 1026** 1027** <blockquote><pre> 1028** INSERT INTO table1 VALUES('It's a happy day!'); 1029** </pre></blockquote> 1030** 1031** This second example is an SQL syntax error. As a general rule you 1032** should always use %q instead of %s when inserting text into a string 1033** literal. 1034** 1035** The %Q option works like %q except it also adds single quotes around 1036** the outside of the total string. Or if the parameter in the argument 1037** list is a NULL pointer, %Q substitutes the text "NULL" (without single 1038** quotes) in place of the %Q option. So, for example, one could say: 1039** 1040** <blockquote><pre> 1041** char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES(%Q)", zText); 1042** sqlite3_exec(db, zSQL, 0, 0, 0); 1043** sqlite3_free(zSQL); 1044** </pre></blockquote> 1045** 1046** The code above will render a correct SQL statement in the zSQL 1047** variable even if the zText variable is a NULL pointer. 1048** 1049** The "%z" formatting option works exactly like "%s" with the 1050** addition that after the string has been read and copied into 1051** the result, [sqlite3_free()] is called on the input string. 1052*/ 1053char *sqlite3_mprintf(const char*,...); 1054char *sqlite3_vmprintf(const char*, va_list); 1055char *sqlite3_snprintf(int,char*,const char*, ...); 1056 1057/* 1058** CAPI3REF: Memory Allocation Subsystem 1059** 1060** The SQLite core uses these three routines for all of its own 1061** internal memory allocation needs. The default implementation 1062** of the memory allocation subsystem uses the malloc(), realloc() 1063** and free() provided by the standard C library. However, if 1064** SQLite is compiled with the following C preprocessor macro 1065** 1066** <blockquote> SQLITE_OMIT_MEMORY_ALLOCATION </blockquote> 1067** 1068** then no implementation is provided for these routines by 1069** SQLite. The application that links against SQLite is 1070** expected to provide its own implementation. If the application 1071** does provide its own implementation for these routines, then 1072** it must also provide an implementation for 1073** [sqlite3_memory_alarm()]. 1074** 1075** <b>Exception:</b> The windows OS interface layer calls 1076** the system malloc() and free() directly when converting 1077** filenames between the UTF-8 encoding used by SQLite 1078** and whatever filename encoding is used by the particular windows 1079** installation. Memory allocation errors are detected, but 1080** they are reported back as [SQLITE_CANTOPEN] or 1081** [SQLITE_IOERR] rather than [SQLITE_NOMEM]. 1082*/ 1083void *sqlite3_malloc(int); 1084void *sqlite3_realloc(void*, int); 1085void sqlite3_free(void*); 1086 1087/* 1088** CAPI3REF: Memory Allocator Statistics 1089** 1090** In addition to the basic three allocation routines 1091** [sqlite3_malloc()], [sqlite3_free()], and [sqlite3_realloc()], 1092** the memory allocation subsystem included with the SQLite 1093** sources provides the interfaces shown below. 1094** 1095** The first of these two routines returns the amount of memory 1096** currently outstanding (malloced but not freed). The second 1097** returns the largest instantaneous amount of outstanding 1098** memory. The highwater mark is reset if the argument is 1099** true. The SQLite core does not use either of these routines 1100** and so they do not have to be implemented by the application 1101** if SQLITE_OMIT_MEMORY_ALLOCATION is defined. These routines 1102** are provided by the default memory subsystem for diagnostic 1103** purposes. 1104*/ 1105sqlite3_int64 sqlite3_memory_used(void); 1106sqlite3_int64 sqlite3_memory_highwater(int resetFlag); 1107 1108/* 1109** CAPI3REF: Memory Allocation Alarms 1110** 1111** The [sqlite3_memory_alarm] routine is used to register 1112** a callback on memory allocation events. 1113** 1114** This routine registers or clears a callbacks that fires when 1115** the amount of memory allocated exceeds iThreshold. Only 1116** a single callback can be registered at a time. Each call 1117** to [sqlite3_memory_alarm()] overwrites the previous callback. 1118** The callback is disabled by setting xCallback to a NULL 1119** pointer. 1120** 1121** The parameters to the callback are the pArg value, the 1122** amount of memory currently in use, and the size of the 1123** allocation that provoked the callback. The callback will 1124** presumably invoke [sqlite3_free()] to free up memory space. 1125** The callback may invoke [sqlite3_malloc()] or [sqlite3_realloc()] 1126** but if it does, no additional callbacks will be invoked by 1127** the recursive calls. 1128** 1129** The [sqlite3_soft_heap_limit()] interface works by registering 1130** a memory alarm at the soft heap limit and invoking 1131** [sqlite3_release_memory()] in the alarm callback. Application 1132** programs should not attempt to use the [sqlite3_memory_alarm()] 1133** interface because doing so will interfere with the 1134** [sqlite3_soft_heap_limit()] module. This interface is exposed 1135** only so that applications can provide their own 1136** alternative implementation when the SQLite core is 1137** compiled with SQLITE_OMIT_MEMORY_ALLOCATION. 1138*/ 1139int sqlite3_memory_alarm( 1140 void(*xCallback)(void *pArg, sqlite3_int64 used, int N), 1141 void *pArg, 1142 sqlite3_int64 iThreshold 1143); 1144 1145 1146/* 1147** CAPI3REF: Compile-Time Authorization Callbacks 1148*** 1149** This routine registers a authorizer callback with the SQLite library. 1150** The authorizer callback is invoked as SQL statements are being compiled 1151** by [sqlite3_prepare()] or its variants [sqlite3_prepare_v2()], 1152** [sqlite3_prepare16()] and [sqlite3_prepare16_v2()]. At various 1153** points during the compilation process, as logic is being created 1154** to perform various actions, the authorizer callback is invoked to 1155** see if those actions are allowed. The authorizer callback should 1156** return SQLITE_OK to allow the action, [SQLITE_IGNORE] to disallow the 1157** specific action but allow the SQL statement to continue to be 1158** compiled, or [SQLITE_DENY] to cause the entire SQL statement to be 1159** rejected with an error. 1160** 1161** Depending on the action, the [SQLITE_IGNORE] and [SQLITE_DENY] return 1162** codes might mean something different or they might mean the same 1163** thing. If the action is, for example, to perform a delete opertion, 1164** then [SQLITE_IGNORE] and [SQLITE_DENY] both cause the statement compilation 1165** to fail with an error. But if the action is to read a specific column 1166** from a specific table, then [SQLITE_DENY] will cause the entire 1167** statement to fail but [SQLITE_IGNORE] will cause a NULL value to be 1168** read instead of the actual column value. 1169** 1170** The first parameter to the authorizer callback is a copy of 1171** the third parameter to the sqlite3_set_authorizer() interface. 1172** The second parameter to the callback is an integer 1173** [SQLITE_COPY | action code] that specifies the particular action 1174** to be authorized. The available action codes are 1175** [SQLITE_COPY | documented separately]. The third through sixth 1176** parameters to the callback are strings that contain additional 1177** details about the action to be authorized. 1178** 1179** An authorizer is used when preparing SQL statements from an untrusted 1180** source, to ensure that the SQL statements do not try to access data 1181** that they are not allowed to see, or that they do not try to 1182** execute malicious statements that damage the database. For 1183** example, an application may allow a user to enter arbitrary 1184** SQL queries for evaluation by a database. But the application does 1185** not want the user to be able to make arbitrary changes to the 1186** database. An authorizer could then be put in place while the 1187** user-entered SQL is being prepared that disallows everything 1188** except SELECT statements. 1189** 1190** Only a single authorizer can be in place on a database connection 1191** at a time. Each call to sqlite3_set_authorizer overrides the 1192** previous call. A NULL authorizer means that no authorization 1193** callback is invoked. The default authorizer is NULL. 1194** 1195** Note that the authorizer callback is invoked only during 1196** [sqlite3_prepare()] or its variants. Authorization is not 1197** performed during statement evaluation in [sqlite3_step()]. 1198*/ 1199int sqlite3_set_authorizer( 1200 sqlite3*, 1201 int (*xAuth)(void*,int,const char*,const char*,const char*,const char*), 1202 void *pUserData 1203); 1204 1205/* 1206** CAPI3REF: Authorizer Return Codes 1207** 1208** The [sqlite3_set_authorizer | authorizer callback function] must 1209** return either [SQLITE_OK] or one of these two constants in order 1210** to signal SQLite whether or not the action is permitted. See the 1211** [sqlite3_set_authorizer | authorizer documentation] for additional 1212** information. 1213*/ 1214#define SQLITE_DENY 1 /* Abort the SQL statement with an error */ 1215#define SQLITE_IGNORE 2 /* Don't allow access, but don't generate an error */ 1216 1217/* 1218** CAPI3REF: Authorizer Action Codes 1219** 1220** The [sqlite3_set_authorizer()] interface registers a callback function 1221** that is invoked to authorizer certain SQL statement actions. The 1222** second parameter to the callback is an integer code that specifies 1223** what action is being authorized. These are the integer action codes that 1224** the authorizer callback may be passed. 1225** 1226** These action code values signify what kind of operation is to be 1227** authorized. The 3rd and 4th parameters to the authorization callback 1228** function will be parameters or NULL depending on which of these 1229** codes is used as the second parameter. The 5th parameter to the 1230** authorizer callback is the name of the database ("main", "temp", 1231** etc.) if applicable. The 6th parameter to the authorizer callback 1232** is the name of the inner-most trigger or view that is responsible for 1233** the access attempt or NULL if this access attempt is directly from 1234** top-level SQL code. 1235*/ 1236/******************************************* 3rd ************ 4th ***********/ 1237#define SQLITE_CREATE_INDEX 1 /* Index Name Table Name */ 1238#define SQLITE_CREATE_TABLE 2 /* Table Name NULL */ 1239#define SQLITE_CREATE_TEMP_INDEX 3 /* Index Name Table Name */ 1240#define SQLITE_CREATE_TEMP_TABLE 4 /* Table Name NULL */ 1241#define SQLITE_CREATE_TEMP_TRIGGER 5 /* Trigger Name Table Name */ 1242#define SQLITE_CREATE_TEMP_VIEW 6 /* View Name NULL */ 1243#define SQLITE_CREATE_TRIGGER 7 /* Trigger Name Table Name */ 1244#define SQLITE_CREATE_VIEW 8 /* View Name NULL */ 1245#define SQLITE_DELETE 9 /* Table Name NULL */ 1246#define SQLITE_DROP_INDEX 10 /* Index Name Table Name */ 1247#define SQLITE_DROP_TABLE 11 /* Table Name NULL */ 1248#define SQLITE_DROP_TEMP_INDEX 12 /* Index Name Table Name */ 1249#define SQLITE_DROP_TEMP_TABLE 13 /* Table Name NULL */ 1250#define SQLITE_DROP_TEMP_TRIGGER 14 /* Trigger Name Table Name */ 1251#define SQLITE_DROP_TEMP_VIEW 15 /* View Name NULL */ 1252#define SQLITE_DROP_TRIGGER 16 /* Trigger Name Table Name */ 1253#define SQLITE_DROP_VIEW 17 /* View Name NULL */ 1254#define SQLITE_INSERT 18 /* Table Name NULL */ 1255#define SQLITE_PRAGMA 19 /* Pragma Name 1st arg or NULL */ 1256#define SQLITE_READ 20 /* Table Name Column Name */ 1257#define SQLITE_SELECT 21 /* NULL NULL */ 1258#define SQLITE_TRANSACTION 22 /* NULL NULL */ 1259#define SQLITE_UPDATE 23 /* Table Name Column Name */ 1260#define SQLITE_ATTACH 24 /* Filename NULL */ 1261#define SQLITE_DETACH 25 /* Database Name NULL */ 1262#define SQLITE_ALTER_TABLE 26 /* Database Name Table Name */ 1263#define SQLITE_REINDEX 27 /* Index Name NULL */ 1264#define SQLITE_ANALYZE 28 /* Table Name NULL */ 1265#define SQLITE_CREATE_VTABLE 29 /* Table Name Module Name */ 1266#define SQLITE_DROP_VTABLE 30 /* Table Name Module Name */ 1267#define SQLITE_FUNCTION 31 /* Function Name NULL */ 1268#define SQLITE_COPY 0 /* No longer used */ 1269 1270/* 1271** CAPI3REF: Tracing And Profiling Functions 1272** 1273** These routines register callback functions that can be used for 1274** tracing and profiling the execution of SQL statements. 1275** The callback function registered by sqlite3_trace() is invoked 1276** at the first [sqlite3_step()] for the evaluation of an SQL statement. 1277** The callback function registered by sqlite3_profile() is invoked 1278** as each SQL statement finishes and includes 1279** information on how long that statement ran. 1280** 1281** The sqlite3_profile() API is currently considered experimental and 1282** is subject to change. 1283*/ 1284void *sqlite3_trace(sqlite3*, void(*xTrace)(void*,const char*), void*); 1285void *sqlite3_profile(sqlite3*, 1286 void(*xProfile)(void*,const char*,sqlite3_uint64), void*); 1287 1288/* 1289** CAPI3REF: Query Progress Callbacks 1290** 1291** This routine configures a callback function - the progress callback - that 1292** is invoked periodically during long running calls to [sqlite3_exec()], 1293** [sqlite3_step()] and [sqlite3_get_table()]. An example use for this 1294** interface is to keep a GUI updated during a large query. 1295** 1296** The progress callback is invoked once for every N virtual machine opcodes, 1297** where N is the second argument to this function. The progress callback 1298** itself is identified by the third argument to this function. The fourth 1299** argument to this function is a void pointer passed to the progress callback 1300** function each time it is invoked. 1301** 1302** If a call to [sqlite3_exec()], [sqlite3_step()], or [sqlite3_get_table()] 1303** results in fewer than N opcodes being executed, then the progress 1304** callback is never invoked. 1305** 1306** Only a single progress callback function may be registered for each 1307** open database connection. Every call to sqlite3_progress_handler() 1308** overwrites the results of the previous call. 1309** To remove the progress callback altogether, pass NULL as the third 1310** argument to this function. 1311** 1312** If the progress callback returns a result other than 0, then the current 1313** query is immediately terminated and any database changes rolled back. 1314** The containing [sqlite3_exec()], [sqlite3_step()], or 1315** [sqlite3_get_table()] call returns SQLITE_INTERRUPT. This feature 1316** can be used, for example, to implement the "Cancel" button on a 1317** progress dialog box in a GUI. 1318*/ 1319void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*); 1320 1321/* 1322** CAPI3REF: Opening A New Database Connection 1323** 1324** Open the sqlite database file "filename". The "filename" is UTF-8 1325** encoded for [sqlite3_open()] and [sqlite3_open_v2()] and UTF-16 encoded 1326** in the native byte order for [sqlite3_open16()]. 1327** An [sqlite3*] handle is returned in *ppDb, even 1328** if an error occurs. If the database is opened (or created) successfully, 1329** then [SQLITE_OK] is returned. Otherwise an error code is returned. The 1330** [sqlite3_errmsg()] or [sqlite3_errmsg16()] routines can be used to obtain 1331** an English language description of the error. 1332** 1333** The default encoding for the database will be UTF-8 if 1334** [sqlite3_open()] or [sqlite3_open_v2()] is called and 1335** UTF-16 if [sqlite3_open16()] is used. 1336** 1337** Whether or not an error occurs when it is opened, resources associated 1338** with the [sqlite3*] handle should be released by passing it to 1339** [sqlite3_close()] when it is no longer required. 1340** 1341** The [sqlite3_open_v2()] interface works like [sqlite3_open()] except that 1342** provides two additional parameters for additional control over the 1343** new database connection. The flags parameter can be one of: 1344** 1345** <ol> 1346** <li> [SQLITE_OPEN_READONLY] 1347** <li> [SQLITE_OPEN_READWRITE] 1348** <li> [SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE] 1349** </ol> 1350** 1351** The first value opens the database read-only. If the database does 1352** not previously exist, an error is returned. The second option opens 1353** the database for reading and writing if possible, or reading only if 1354** if the file is write protected. In either case the database must already 1355** exist or an error is returned. The third option opens the database 1356** for reading and writing and creates it if it does not already exist. 1357** The third options is behavior that is always used for [sqlite3_open()] 1358** and [sqlite3_open16()]. 1359** 1360** If the filename is ":memory:" or an empty string, then an private 1361** in-memory database is created for the connection. This in-memory 1362** database will vanish when the database connection is closed. Future 1363** version of SQLite might make use of additional special filenames 1364** that begin with the ":" character. It is recommended that 1365** when a database filename really does begin with 1366** ":" that you prefix the filename with a pathname like "./" to 1367** avoid ambiguity. 1368** 1369** The fourth parameter to sqlite3_open_v2() is the name of the 1370** [sqlite3_vfs] object that defines the operating system 1371** interface that the new database connection should use. If the 1372** fourth parameter is a NULL pointer then the default [sqlite3_vfs] 1373** object is used. 1374** 1375** <b>Note to windows users:</b> The encoding used for the filename argument 1376** of [sqlite3_open()] and [sqlite3_open_v2()] must be UTF-8, not whatever 1377** codepage is currently defined. Filenames containing international 1378** characters must be converted to UTF-8 prior to passing them into 1379** [sqlite3_open()] or [sqlite3_open_v2()]. 1380*/ 1381int sqlite3_open( 1382 const char *filename, /* Database filename (UTF-8) */ 1383 sqlite3 **ppDb /* OUT: SQLite db handle */ 1384); 1385int sqlite3_open16( 1386 const void *filename, /* Database filename (UTF-16) */ 1387 sqlite3 **ppDb /* OUT: SQLite db handle */ 1388); 1389int sqlite3_open_v2( 1390 const char *filename, /* Database filename (UTF-8) */ 1391 sqlite3 **ppDb, /* OUT: SQLite db handle */ 1392 int flags, /* Flags */ 1393 const char *zVfs /* Name of VFS module to use */ 1394); 1395 1396/* 1397** CAPI3REF: Error Codes And Messages 1398** 1399** The sqlite3_errcode() interface returns the numeric 1400** [SQLITE_OK | result code] or [SQLITE_IOERR_READ | extended result code] 1401** for the most recent failed sqlite3_* API call associated 1402** with [sqlite3] handle 'db'. If a prior API call failed but the 1403** most recent API call succeeded, the return value from sqlite3_errcode() 1404** is undefined. 1405** 1406** The sqlite3_errmsg() and sqlite3_errmsg16() return English-langauge 1407** text that describes the error, as either UTF8 or UTF16 respectively. 1408** Memory to hold the error message string is managed internally. The 1409** string may be overwritten or deallocated by subsequent calls to SQLite 1410** interface functions. 1411** 1412** Calls to many sqlite3_* functions set the error code and string returned 1413** by [sqlite3_errcode()], [sqlite3_errmsg()], and [sqlite3_errmsg16()] 1414** (overwriting the previous values). Note that calls to [sqlite3_errcode()], 1415** [sqlite3_errmsg()], and [sqlite3_errmsg16()] themselves do not affect the 1416** results of future invocations. Calls to API routines that do not return 1417** an error code (example: [sqlite3_data_count()]) do not 1418** change the error code returned by this routine. Interfaces that are 1419** not associated with a specific database connection (examples: 1420** [sqlite3_mprintf()] or [sqlite3_enable_shared_cache()] do not change 1421** the return code. 1422** 1423** Assuming no other intervening sqlite3_* API calls are made, the error 1424** code returned by this function is associated with the same error as 1425** the strings returned by [sqlite3_errmsg()] and [sqlite3_errmsg16()]. 1426*/ 1427int sqlite3_errcode(sqlite3 *db); 1428const char *sqlite3_errmsg(sqlite3*); 1429const void *sqlite3_errmsg16(sqlite3*); 1430 1431/* 1432** CAPI3REF: SQL Statement Object 1433** 1434** Instance of this object represent single SQL statements. This 1435** is variously known as a "prepared statement" or a 1436** "compiled SQL statement" or simply as a "statement". 1437** 1438** The life of a statement object goes something like this: 1439** 1440** <ol> 1441** <li> Create the object using [sqlite3_prepare_v2()] or a related 1442** function. 1443** <li> Bind values to host parameters using 1444** [sqlite3_bind_blob | sqlite3_bind_* interfaces]. 1445** <li> Run the SQL by calling [sqlite3_step()] one or more times. 1446** <li> Reset the statement using [sqlite3_reset()] then go back 1447** to step 2. Do this zero or more times. 1448** <li> Destroy the object using [sqlite3_finalize()]. 1449** </ol> 1450** 1451** Refer to documentation on individual methods above for additional 1452** information. 1453*/ 1454typedef struct sqlite3_stmt sqlite3_stmt; 1455 1456/* 1457** CAPI3REF: Compiling An SQL Statement 1458** 1459** To execute an SQL query, it must first be compiled into a byte-code 1460** program using one of these routines. 1461** 1462** The first argument "db" is an [sqlite3 | SQLite database handle] 1463** obtained from a prior call to [sqlite3_open()] or [sqlite3_open16()]. 1464** The second argument "zSql" is the statement to be compiled, encoded 1465** as either UTF-8 or UTF-16. The sqlite3_prepare() and sqlite3_prepare_v2() 1466** interfaces uses UTF-8 and sqlite3_prepare16() and sqlite3_prepare16_v2() 1467** use UTF-16. 1468** 1469** If the nByte argument is less 1470** than zero, then zSql is read up to the first zero terminator. If 1471** nByte is non-negative, then it is the maximum number of 1472** bytes read from zSql. When nByte is non-negative, the 1473** zSql string ends at either the first '\000' character or 1474** until the nByte-th byte, whichever comes first. 1475** 1476** *pzTail is made to point to the first byte past the end of the first 1477** SQL statement in zSql. This routine only compiles the first statement 1478** in zSql, so *pzTail is left pointing to what remains uncompiled. 1479** 1480** *ppStmt is left pointing to a compiled 1481** [sqlite3_stmt | SQL statement structure] that can be 1482** executed using [sqlite3_step()]. Or if there is an error, *ppStmt may be 1483** set to NULL. If the input text contained no SQL (if the input is and 1484** empty string or a comment) then *ppStmt is set to NULL. The calling 1485** procedure is responsible for deleting the compiled SQL statement 1486** using [sqlite3_finalize()] after it has finished with it. 1487** 1488** On success, [SQLITE_OK] is returned. Otherwise an 1489** [SQLITE_ERROR | error code] is returned. 1490** 1491** The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are 1492** recommended for all new programs. The two older interfaces are retained 1493** for backwards compatibility, but their use is discouraged. 1494** In the "v2" interfaces, the prepared statement 1495** that is returned (the [sqlite3_stmt] object) contains a copy of the 1496** original SQL text. This causes the [sqlite3_step()] interface to 1497** behave a differently in two ways: 1498** 1499** <ol> 1500** <li> 1501** If the database schema changes, instead of returning [SQLITE_SCHEMA] as it 1502** always used to do, [sqlite3_step()] will automatically recompile the SQL 1503** statement and try to run it again. If the schema has changed in a way 1504** that makes the statement no longer valid, [sqlite3_step()] will still 1505** return [SQLITE_SCHEMA]. But unlike the legacy behavior, [SQLITE_SCHEMA] is 1506** now a fatal error. Calling [sqlite3_prepare_v2()] again will not make the 1507** error go away. Note: use [sqlite3_errmsg()] to find the text of the parsing 1508** error that results in an [SQLITE_SCHEMA] return. 1509** </li> 1510** 1511** <li> 1512** When an error occurs, 1513** [sqlite3_step()] will return one of the detailed 1514** [SQLITE_ERROR | result codes] or 1515** [SQLITE_IOERR_READ | extended result codes] such as directly. 1516** The legacy behavior was that [sqlite3_step()] would only return a generic 1517** [SQLITE_ERROR] result code and you would have to make a second call to 1518** [sqlite3_reset()] in order to find the underlying cause of the problem. 1519** With the "v2" prepare interfaces, the underlying reason for the error is 1520** returned immediately. 1521** </li> 1522** </ol> 1523*/ 1524int sqlite3_prepare( 1525 sqlite3 *db, /* Database handle */ 1526 const char *zSql, /* SQL statement, UTF-8 encoded */ 1527 int nByte, /* Maximum length of zSql in bytes. */ 1528 sqlite3_stmt **ppStmt, /* OUT: Statement handle */ 1529 const char **pzTail /* OUT: Pointer to unused portion of zSql */ 1530); 1531int sqlite3_prepare_v2( 1532 sqlite3 *db, /* Database handle */ 1533 const char *zSql, /* SQL statement, UTF-8 encoded */ 1534 int nByte, /* Maximum length of zSql in bytes. */ 1535 sqlite3_stmt **ppStmt, /* OUT: Statement handle */ 1536 const char **pzTail /* OUT: Pointer to unused portion of zSql */ 1537); 1538int sqlite3_prepare16( 1539 sqlite3 *db, /* Database handle */ 1540 const void *zSql, /* SQL statement, UTF-16 encoded */ 1541 int nByte, /* Maximum length of zSql in bytes. */ 1542 sqlite3_stmt **ppStmt, /* OUT: Statement handle */ 1543 const void **pzTail /* OUT: Pointer to unused portion of zSql */ 1544); 1545int sqlite3_prepare16_v2( 1546 sqlite3 *db, /* Database handle */ 1547 const void *zSql, /* SQL statement, UTF-16 encoded */ 1548 int nByte, /* Maximum length of zSql in bytes. */ 1549 sqlite3_stmt **ppStmt, /* OUT: Statement handle */ 1550 const void **pzTail /* OUT: Pointer to unused portion of zSql */ 1551); 1552 1553/* 1554** CAPI3REF: Dynamically Typed Value Object 1555** 1556** SQLite uses dynamic typing for the values it stores. Values can 1557** be integers, floating point values, strings, BLOBs, or NULL. When 1558** passing around values internally, each value is represented as 1559** an instance of the sqlite3_value object. 1560*/ 1561typedef struct Mem sqlite3_value; 1562 1563/* 1564** CAPI3REF: SQL Function Context Object 1565** 1566** The context in which an SQL function executes is stored in an 1567** sqlite3_context object. A pointer to such an object is the 1568** first parameter to user-defined SQL functions. 1569*/ 1570typedef struct sqlite3_context sqlite3_context; 1571 1572/* 1573** CAPI3REF: Binding Values To Prepared Statements 1574** 1575** In the SQL strings input to [sqlite3_prepare_v2()] and its variants, 1576** one or more literals can be replace by a parameter in one of these 1577** forms: 1578** 1579** <ul> 1580** <li> ? 1581** <li> ?NNN 1582** <li> :AAA 1583** <li> @AAA 1584** <li> $VVV 1585** </ul> 1586** 1587** In the parameter forms shown above NNN is an integer literal, 1588** AAA is an alphanumeric identifier and VVV is a variable name according 1589** to the syntax rules of the TCL programming language. 1590** The values of these parameters (also called "host parameter names") 1591** can be set using the sqlite3_bind_*() routines defined here. 1592** 1593** The first argument to the sqlite3_bind_*() routines always is a pointer 1594** to the [sqlite3_stmt] object returned from [sqlite3_prepare_v2()] or 1595** its variants. The second 1596** argument is the index of the parameter to be set. The first parameter has 1597** an index of 1. When the same named parameter is used more than once, second 1598** and subsequent 1599** occurrences have the same index as the first occurrence. The index for 1600** named parameters can be looked up using the 1601** [sqlite3_bind_parameter_name()] API if desired. The index for "?NNN" 1602** parametes is the value of NNN. 1603** The NNN value must be between 1 and the compile-time 1604** parameter SQLITE_MAX_VARIABLE_NUMBER (default value: 999). 1605** See <a href="limits.html">limits.html</a> for additional information. 1606** 1607** The third argument is the value to bind to the parameter. 1608** 1609** In those 1610** routines that have a fourth argument, its value is the number of bytes 1611** in the parameter. To be clear: the value is the number of bytes in the 1612** string, not the number of characters. The number 1613** of bytes does not include the zero-terminator at the end of strings. 1614** If the fourth parameter is negative, the length of the string is 1615** number of bytes up to the first zero terminator. 1616** 1617** The fifth argument to sqlite3_bind_blob(), sqlite3_bind_text(), and 1618** sqlite3_bind_text16() is a destructor used to dispose of the BLOB or 1619** text after SQLite has finished with it. If the fifth argument is the 1620** special value [SQLITE_STATIC], then the library assumes that the information 1621** is in static, unmanaged space and does not need to be freed. If the 1622** fifth argument has the value [SQLITE_TRANSIENT], then SQLite makes its 1623** own private copy of the data immediately, before the sqlite3_bind_*() 1624** routine returns. 1625** 1626** The sqlite3_bind_zeroblob() routine binds a BLOB of length n that 1627** is filled with zeros. A zeroblob uses a fixed amount of memory 1628** (just an integer to hold it size) while it is being processed. 1629** Zeroblobs are intended to serve as place-holders for BLOBs whose 1630** content is later written using 1631** [sqlite3_blob_open | increment BLOB I/O] routines. 1632** 1633** The sqlite3_bind_*() routines must be called after 1634** [sqlite3_prepare_v2()] (and its variants) or [sqlite3_reset()] and 1635** before [sqlite3_step()]. 1636** Bindings are not cleared by the [sqlite3_reset()] routine. 1637** Unbound parameters are interpreted as NULL. 1638** 1639** These routines return [SQLITE_OK] on success or an error code if 1640** anything goes wrong. [SQLITE_RANGE] is returned if the parameter 1641** index is out of range. [SQLITE_NOMEM] is returned if malloc fails. 1642** [SQLITE_MISUSE] is returned if these routines are called on a virtual 1643** machine that is the wrong state or which has already been finalized. 1644*/ 1645int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*)); 1646int sqlite3_bind_double(sqlite3_stmt*, int, double); 1647int sqlite3_bind_int(sqlite3_stmt*, int, int); 1648int sqlite3_bind_int64(sqlite3_stmt*, int, sqlite3_int64); 1649int sqlite3_bind_null(sqlite3_stmt*, int); 1650int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*)); 1651int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int, void(*)(void*)); 1652int sqlite3_bind_value(sqlite3_stmt*, int, const sqlite3_value*); 1653int sqlite3_bind_zeroblob(sqlite3_stmt*, int, int n); 1654 1655/* 1656** CAPI3REF: Number Of Host Parameters 1657** 1658** Return the largest host parameter index in the precompiled statement given 1659** as the argument. When the host parameters are of the forms like ":AAA" 1660** or "?", then they are assigned sequential increasing numbers beginning 1661** with one, so the value returned is the number of parameters. However 1662** if the same host parameter name is used multiple times, each occurrance 1663** is given the same number, so the value returned in that case is the number 1664** of unique host parameter names. If host parameters of the form "?NNN" 1665** are used (where NNN is an integer) then there might be gaps in the 1666** numbering and the value returned by this interface is the index of the 1667** host parameter with the largest index value. 1668** 1669** The prepared statement must not be [sqlite3_finalize | finalized] 1670** prior to this routine returnning. Otherwise the results are undefined 1671** and probably undesirable. 1672*/ 1673int sqlite3_bind_parameter_count(sqlite3_stmt*); 1674 1675/* 1676** CAPI3REF: Name Of A Host Parameter 1677** 1678** This routine returns a pointer to the name of the n-th parameter in a 1679** [sqlite3_stmt | prepared statement]. 1680** Host parameters of the form ":AAA" or "@AAA" or "$VVV" have a name 1681** which is the string ":AAA" or "@AAA" or "$VVV". 1682** In other words, the initial ":" or "$" or "@" 1683** is included as part of the name. 1684** Parameters of the form "?" or "?NNN" have no name. 1685** 1686** The first bound parameter has an index of 1, not 0. 1687** 1688** If the value n is out of range or if the n-th parameter is nameless, 1689** then NULL is returned. The returned string is always in the 1690** UTF-8 encoding even if the named parameter was originally specified 1691** as UTF-16 in [sqlite3_prepare16()] or [sqlite3_prepare16_v2()]. 1692*/ 1693const char *sqlite3_bind_parameter_name(sqlite3_stmt*, int); 1694 1695/* 1696** CAPI3REF: Index Of A Parameter With A Given Name 1697** 1698** This routine returns the index of a host parameter with the given name. 1699** The name must match exactly. If no parameter with the given name is 1700** found, return 0. Parameter names must be UTF8. 1701*/ 1702int sqlite3_bind_parameter_index(sqlite3_stmt*, const char *zName); 1703 1704/* 1705** CAPI3REF: Reset All Bindings On A Prepared Statement 1706** 1707** Contrary to the intuition of many, [sqlite3_reset()] does not 1708** reset the [sqlite3_bind_blob | bindings] on a 1709** [sqlite3_stmt | prepared statement]. Use this routine to 1710** reset all host parameters to NULL. 1711*/ 1712int sqlite3_clear_bindings(sqlite3_stmt*); 1713 1714/* 1715** CAPI3REF: Number Of Columns In A Result Set 1716** 1717** Return the number of columns in the result set returned by the 1718** [sqlite3_stmt | compiled SQL statement]. This routine returns 0 1719** if pStmt is an SQL statement that does not return data (for 1720** example an UPDATE). 1721*/ 1722int sqlite3_column_count(sqlite3_stmt *pStmt); 1723 1724/* 1725** CAPI3REF: Column Names In A Result Set 1726** 1727** These routines return the name assigned to a particular column 1728** in the result set of a SELECT statement. The sqlite3_column_name() 1729** interface returns a pointer to a UTF8 string and sqlite3_column_name16() 1730** returns a pointer to a UTF16 string. The first parameter is the 1731** [sqlite3_stmt | prepared statement] that implements the SELECT statement. 1732** The second parameter is the column number. The left-most column is 1733** number 0. 1734** 1735** The returned string pointer is valid until either the 1736** [sqlite3_stmt | prepared statement] is destroyed by [sqlite3_finalize()] 1737** or until the next call sqlite3_column_name() or sqlite3_column_name16() 1738** on the same column. 1739** 1740** If sqlite3_malloc() fails during the processing of either routine 1741** (for example during a conversion from UTF-8 to UTF-16) then a 1742** NULL pointer is returned. 1743*/ 1744const char *sqlite3_column_name(sqlite3_stmt*, int N); 1745const void *sqlite3_column_name16(sqlite3_stmt*, int N); 1746 1747/* 1748** CAPI3REF: Source Of Data In A Query Result 1749** 1750** These routines provide a means to determine what column of what 1751** table in which database a result of a SELECT statement comes from. 1752** The name of the database or table or column can be returned as 1753** either a UTF8 or UTF16 string. The _database_ routines return 1754** the database name, the _table_ routines return the table name, and 1755** the origin_ routines return the column name. 1756** The returned string is valid until 1757** the [sqlite3_stmt | prepared statement] is destroyed using 1758** [sqlite3_finalize()] or until the same information is requested 1759** again in a different encoding. 1760** 1761** The names returned are the original un-aliased names of the 1762** database, table, and column. 1763** 1764** The first argument to the following calls is a 1765** [sqlite3_stmt | compiled SQL statement]. 1766** These functions return information about the Nth column returned by 1767** the statement, where N is the second function argument. 1768** 1769** If the Nth column returned by the statement is an expression 1770** or subquery and is not a column value, then all of these functions 1771** return NULL. Otherwise, they return the 1772** name of the attached database, table and column that query result 1773** column was extracted from. 1774** 1775** As with all other SQLite APIs, those postfixed with "16" return UTF-16 1776** encoded strings, the other functions return UTF-8. 1777** 1778** These APIs are only available if the library was compiled with the 1779** SQLITE_ENABLE_COLUMN_METADATA preprocessor symbol defined. 1780** 1781** If two or more threads call one or more of these routines against the same 1782** prepared statement and column at the same time then the results are 1783** undefined. 1784*/ 1785const char *sqlite3_column_database_name(sqlite3_stmt*,int); 1786const void *sqlite3_column_database_name16(sqlite3_stmt*,int); 1787const char *sqlite3_column_table_name(sqlite3_stmt*,int); 1788const void *sqlite3_column_table_name16(sqlite3_stmt*,int); 1789const char *sqlite3_column_origin_name(sqlite3_stmt*,int); 1790const void *sqlite3_column_origin_name16(sqlite3_stmt*,int); 1791 1792/* 1793** CAPI3REF: Declared Datatype Of A Query Result 1794** 1795** The first parameter is a [sqlite3_stmt | compiled SQL statement]. 1796** If this statement is a SELECT statement and the Nth column of the 1797** returned result set of that SELECT is a table column (not an 1798** expression or subquery) then the declared type of the table 1799** column is returned. If the Nth column of the result set is an 1800** expression or subquery, then a NULL pointer is returned. 1801** The returned string is always UTF-8 encoded. For example, in 1802** the database schema: 1803** 1804** CREATE TABLE t1(c1 VARIANT); 1805** 1806** And the following statement compiled: 1807** 1808** SELECT c1 + 1, c1 FROM t1; 1809** 1810** Then this routine would return the string "VARIANT" for the second 1811** result column (i==1), and a NULL pointer for the first result column 1812** (i==0). 1813** 1814** SQLite uses dynamic run-time typing. So just because a column 1815** is declared to contain a particular type does not mean that the 1816** data stored in that column is of the declared type. SQLite is 1817** strongly typed, but the typing is dynamic not static. Type 1818** is associated with individual values, not with the containers 1819** used to hold those values. 1820*/ 1821const char *sqlite3_column_decltype(sqlite3_stmt *, int i); 1822const void *sqlite3_column_decltype16(sqlite3_stmt*,int); 1823 1824/* 1825** CAPI3REF: Evaluate An SQL Statement 1826** 1827** After an [sqlite3_stmt | SQL statement] has been prepared with a call 1828** to either [sqlite3_prepare_v2()] or [sqlite3_prepare16_v2()] or to one of 1829** the legacy interfaces [sqlite3_prepare()] or [sqlite3_prepare16()], 1830** then this function must be called one or more times to evaluate the 1831** statement. 1832** 1833** The details of the behavior of this sqlite3_step() interface depend 1834** on whether the statement was prepared using the newer "v2" interface 1835** [sqlite3_prepare_v2()] and [sqlite3_prepare16_v2()] or the older legacy 1836** interface [sqlite3_prepare()] and [sqlite3_prepare16()]. The use of the 1837** new "v2" interface is recommended for new applications but the legacy 1838** interface will continue to be supported. 1839** 1840** In the lagacy interface, the return value will be either [SQLITE_BUSY], 1841** [SQLITE_DONE], [SQLITE_ROW], [SQLITE_ERROR], or [SQLITE_MISUSE]. 1842** With the "v2" interface, any of the other [SQLITE_OK | result code] 1843** or [SQLITE_IOERR_READ | extended result code] might be returned as 1844** well. 1845** 1846** [SQLITE_BUSY] means that the database engine was unable to acquire the 1847** database locks it needs to do its job. If the statement is a COMMIT 1848** or occurs outside of an explicit transaction, then you can retry the 1849** statement. If the statement is not a COMMIT and occurs within a 1850** explicit transaction then you should rollback the transaction before 1851** continuing. 1852** 1853** [SQLITE_DONE] means that the statement has finished executing 1854** successfully. sqlite3_step() should not be called again on this virtual 1855** machine without first calling [sqlite3_reset()] to reset the virtual 1856** machine back to its initial state. 1857** 1858** If the SQL statement being executed returns any data, then 1859** [SQLITE_ROW] is returned each time a new row of data is ready 1860** for processing by the caller. The values may be accessed using 1861** the [sqlite3_column_int | column access functions]. 1862** sqlite3_step() is called again to retrieve the next row of data. 1863** 1864** [SQLITE_ERROR] means that a run-time error (such as a constraint 1865** violation) has occurred. sqlite3_step() should not be called again on 1866** the VM. More information may be found by calling [sqlite3_errmsg()]. 1867** With the legacy interface, a more specific error code (example: 1868** [SQLITE_INTERRUPT], [SQLITE_SCHEMA], [SQLITE_CORRUPT], and so forth) 1869** can be obtained by calling [sqlite3_reset()] on the 1870** [sqlite3_stmt | prepared statement]. In the "v2" interface, 1871** the more specific error code is returned directly by sqlite3_step(). 1872** 1873** [SQLITE_MISUSE] means that the this routine was called inappropriately. 1874** Perhaps it was called on a [sqlite3_stmt | prepared statement] that has 1875** already been [sqlite3_finalize | finalized] or on one that had 1876** previously returned [SQLITE_ERROR] or [SQLITE_DONE]. Or it could 1877** be the case that the same database connection is being used by two or 1878** more threads at the same moment in time. 1879** 1880** <b>Goofy Interface Alert:</b> 1881** In the legacy interface, 1882** the sqlite3_step() API always returns a generic error code, 1883** [SQLITE_ERROR], following any error other than [SQLITE_BUSY] 1884** and [SQLITE_MISUSE]. You must call [sqlite3_reset()] or 1885** [sqlite3_finalize()] in order to find one of the specific 1886** [SQLITE_ERROR | result codes] that better describes the error. 1887** We admit that this is a goofy design. The problem has been fixed 1888** with the "v2" interface. If you prepare all of your SQL statements 1889** using either [sqlite3_prepare_v2()] or [sqlite3_prepare16_v2()] instead 1890** of the legacy [sqlite3_prepare()] and [sqlite3_prepare16()], then the 1891** more specific [SQLITE_ERROR | result codes] are returned directly 1892** by sqlite3_step(). The use of the "v2" interface is recommended. 1893*/ 1894int sqlite3_step(sqlite3_stmt*); 1895 1896/* 1897** CAPI3REF: 1898** 1899** Return the number of values in the current row of the result set. 1900** 1901** After a call to [sqlite3_step()] that returns [SQLITE_ROW], this routine 1902** will return the same value as the [sqlite3_column_count()] function. 1903** After [sqlite3_step()] has returned an [SQLITE_DONE], [SQLITE_BUSY], or 1904** a [SQLITE_ERROR | error code], or before [sqlite3_step()] has been 1905** called on the [sqlite3_stmt | prepared statement] for the first time, 1906** this routine returns zero. 1907*/ 1908int sqlite3_data_count(sqlite3_stmt *pStmt); 1909 1910/* 1911** CAPI3REF: Fundamental Datatypes 1912** 1913** Every value in SQLite has one of five fundamental datatypes: 1914** 1915** <ul> 1916** <li> 64-bit signed integer 1917** <li> 64-bit IEEE floating point number 1918** <li> string 1919** <li> BLOB 1920** <li> NULL 1921** </ul> 1922** 1923** These constants are codes for each of those types. 1924** 1925** Note that the SQLITE_TEXT constant was also used in SQLite version 2 1926** for a completely different meaning. Software that links against both 1927** SQLite version 2 and SQLite version 3 should use SQLITE3_TEXT not 1928** SQLITE_TEXT. 1929*/ 1930#define SQLITE_INTEGER 1 1931#define SQLITE_FLOAT 2 1932#define SQLITE_BLOB 4 1933#define SQLITE_NULL 5 1934#ifdef SQLITE_TEXT 1935# undef SQLITE_TEXT 1936#else 1937# define SQLITE_TEXT 3 1938#endif 1939#define SQLITE3_TEXT 3 1940 1941/* 1942** CAPI3REF: Results Values From A Query 1943** 1944** These routines return information about 1945** a single column of the current result row of a query. In every 1946** case the first argument is a pointer to the 1947** [sqlite3_stmt | SQL statement] that is being 1948** evaluated (the [sqlite3_stmt*] that was returned from 1949** [sqlite3_prepare_v2()] or one of its variants) and 1950** the second argument is the index of the column for which information 1951** should be returned. The left-most column of the result set 1952** has an index of 0. 1953** 1954** If the SQL statement is not currently point to a valid row, or if the 1955** the column index is out of range, the result is undefined. 1956** These routines may only be called when the most recent call to 1957** [sqlite3_step()] has returned [SQLITE_ROW] and neither 1958** [sqlite3_reset()] nor [sqlite3_finalize()] has been call subsequently. 1959** If any of these routines are called after [sqlite3_reset()] or 1960** [sqlite3_finalize()] or after [sqlite3_step()] has returned 1961** something other than [SQLITE_ROW], the results are undefined. 1962** If [sqlite3_step()] or [sqlite3_reset()] or [sqlite3_finalize()] 1963** are called from a different thread while any of these routines 1964** are pending, then the results are undefined. 1965** 1966** The sqlite3_column_type() routine returns 1967** [SQLITE_INTEGER | datatype code] for the initial data type 1968** of the result column. The returned value is one of [SQLITE_INTEGER], 1969** [SQLITE_FLOAT], [SQLITE_TEXT], [SQLITE_BLOB], or [SQLITE_NULL]. The value 1970** returned by sqlite3_column_type() is only meaningful if no type 1971** conversions have occurred as described below. After a type conversion, 1972** the value returned by sqlite3_column_type() is undefined. Future 1973** versions of SQLite may change the behavior of sqlite3_column_type() 1974** following a type conversion. 1975** 1976** If the result is a BLOB or UTF-8 string then the sqlite3_column_bytes() 1977** routine returns the number of bytes in that BLOB or string. 1978** If the result is a UTF-16 string, then sqlite3_column_bytes() converts 1979** the string to UTF-8 and then returns the number of bytes. 1980** If the result is a numeric value then sqlite3_column_bytes() uses 1981** [sqlite3_snprintf()] to convert that value to a UTF-8 string and returns 1982** the number of bytes in that string. 1983** The value returned does not include the zero terminator at the end 1984** of the string. For clarity: the value returned is the number of 1985** bytes in the string, not the number of characters. 1986** 1987** The sqlite3_column_bytes16() routine is similar to sqlite3_column_bytes() 1988** but leaves the result in UTF-16 instead of UTF-8. 1989** The zero terminator is not included in this count. 1990** 1991** These routines attempt to convert the value where appropriate. For 1992** example, if the internal representation is FLOAT and a text result 1993** is requested, [sqlite3_snprintf()] is used internally to do the conversion 1994** automatically. The following table details the conversions that 1995** are applied: 1996** 1997** <blockquote> 1998** <table border="1"> 1999** <tr><th> Internal<br>Type <th> Requested<br>Type <th> Conversion 2000** 2001** <tr><td> NULL <td> INTEGER <td> Result is 0 2002** <tr><td> NULL <td> FLOAT <td> Result is 0.0 2003** <tr><td> NULL <td> TEXT <td> Result is NULL pointer 2004** <tr><td> NULL <td> BLOB <td> Result is NULL pointer 2005** <tr><td> INTEGER <td> FLOAT <td> Convert from integer to float 2006** <tr><td> INTEGER <td> TEXT <td> ASCII rendering of the integer 2007** <tr><td> INTEGER <td> BLOB <td> Same as for INTEGER->TEXT 2008** <tr><td> FLOAT <td> INTEGER <td> Convert from float to integer 2009** <tr><td> FLOAT <td> TEXT <td> ASCII rendering of the float 2010** <tr><td> FLOAT <td> BLOB <td> Same as FLOAT->TEXT 2011** <tr><td> TEXT <td> INTEGER <td> Use atoi() 2012** <tr><td> TEXT <td> FLOAT <td> Use atof() 2013** <tr><td> TEXT <td> BLOB <td> No change 2014** <tr><td> BLOB <td> INTEGER <td> Convert to TEXT then use atoi() 2015** <tr><td> BLOB <td> FLOAT <td> Convert to TEXT then use atof() 2016** <tr><td> BLOB <td> TEXT <td> Add a zero terminator if needed 2017** </table> 2018** </blockquote> 2019** 2020** The table above makes reference to standard C library functions atoi() 2021** and atof(). SQLite does not really use these functions. It has its 2022** on equavalent internal routines. The atoi() and atof() names are 2023** used in the table for brevity and because they are familiar to most 2024** C programmers. 2025** 2026** Note that when type conversions occur, pointers returned by prior 2027** calls to sqlite3_column_blob(), sqlite3_column_text(), and/or 2028** sqlite3_column_text16() may be invalidated. 2029** Type conversions and pointer invalidations might occur 2030** in the following cases: 2031** 2032** <ul> 2033** <li><p> The initial content is a BLOB and sqlite3_column_text() 2034** or sqlite3_column_text16() is called. A zero-terminator might 2035** need to be added to the string.</p></li> 2036** 2037** <li><p> The initial content is UTF-8 text and sqlite3_column_bytes16() or 2038** sqlite3_column_text16() is called. The content must be converted 2039** to UTF-16.</p></li> 2040** 2041** <li><p> The initial content is UTF-16 text and sqlite3_column_bytes() or 2042** sqlite3_column_text() is called. The content must be converted 2043** to UTF-8.</p></li> 2044** </ul> 2045** 2046** Conversions between UTF-16be and UTF-16le are always done in place and do 2047** not invalidate a prior pointer, though of course the content of the buffer 2048** that the prior pointer points to will have been modified. Other kinds 2049** of conversion are done in place when it is possible, but sometime it is 2050** not possible and in those cases prior pointers are invalidated. 2051** 2052** The safest and easiest to remember policy is to invoke these routines 2053** in one of the following ways: 2054** 2055** <ul> 2056** <li>sqlite3_column_text() followed by sqlite3_column_bytes()</li> 2057** <li>sqlite3_column_blob() followed by sqlite3_column_bytes()</li> 2058** <li>sqlite3_column_text16() followed by sqlite3_column_bytes16()</li> 2059** </ul> 2060** 2061** In other words, you should call sqlite3_column_text(), sqlite3_column_blob(), 2062** or sqlite3_column_text16() first to force the result into the desired 2063** format, then invoke sqlite3_column_bytes() or sqlite3_column_bytes16() to 2064** find the size of the result. Do not mix call to sqlite3_column_text() or 2065** sqlite3_column_blob() with calls to sqlite3_column_bytes16(). And do not 2066** mix calls to sqlite3_column_text16() with calls to sqlite3_column_bytes(). 2067** 2068** The pointers returned are valid until a type conversion occurs as 2069** described above, or until [sqlite3_step()] or [sqlite3_reset()] or 2070** [sqlite3_finalize()] is called. The memory space used to hold strings 2071** and blobs is freed automatically. Do <b>not</b> pass the pointers returned 2072** [sqlite3_column_blob()], [sqlite_column_text()], etc. into 2073** [sqlite3_free()]. 2074** 2075** If a memory allocation error occurs during the evaluation of any 2076** of these routines, a default value is returned. The default value 2077** is either the integer 0, the floating point number 0.0, or a NULL 2078** pointer. Subsequent calls to [sqlite3_errcode()] will return 2079** [SQLITE_NOMEM]. 2080*/ 2081const void *sqlite3_column_blob(sqlite3_stmt*, int iCol); 2082int sqlite3_column_bytes(sqlite3_stmt*, int iCol); 2083int sqlite3_column_bytes16(sqlite3_stmt*, int iCol); 2084double sqlite3_column_double(sqlite3_stmt*, int iCol); 2085int sqlite3_column_int(sqlite3_stmt*, int iCol); 2086sqlite3_int64 sqlite3_column_int64(sqlite3_stmt*, int iCol); 2087const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol); 2088const void *sqlite3_column_text16(sqlite3_stmt*, int iCol); 2089int sqlite3_column_type(sqlite3_stmt*, int iCol); 2090sqlite3_value *sqlite3_column_value(sqlite3_stmt*, int iCol); 2091 2092/* 2093** CAPI3REF: Destroy A Prepared Statement Object 2094** 2095** The sqlite3_finalize() function is called to delete a 2096** [sqlite3_stmt | compiled SQL statement]. If the statement was 2097** executed successfully, or not executed at all, then SQLITE_OK is returned. 2098** If execution of the statement failed then an 2099** [SQLITE_ERROR | error code] or [SQLITE_IOERR_READ | extended error code] 2100** is returned. 2101** 2102** This routine can be called at any point during the execution of the 2103** [sqlite3_stmt | virtual machine]. If the virtual machine has not 2104** completed execution when this routine is called, that is like 2105** encountering an error or an interrupt. (See [sqlite3_interrupt()].) 2106** Incomplete updates may be rolled back and transactions cancelled, 2107** depending on the circumstances, and the 2108** [SQLITE_ERROR | result code] returned will be [SQLITE_ABORT]. 2109*/ 2110int sqlite3_finalize(sqlite3_stmt *pStmt); 2111 2112/* 2113** CAPI3REF: Reset A Prepared Statement Object 2114** 2115** The sqlite3_reset() function is called to reset a 2116** [sqlite3_stmt | compiled SQL statement] object. 2117** back to it's initial state, ready to be re-executed. 2118** Any SQL statement variables that had values bound to them using 2119** the [sqlite3_bind_blob | sqlite3_bind_*() API] retain their values. 2120** Use [sqlite3_clear_bindings()] to reset the bindings. 2121*/ 2122int sqlite3_reset(sqlite3_stmt *pStmt); 2123 2124/* 2125** CAPI3REF: Create Or Redefine SQL Functions 2126** 2127** The following two functions are used to add SQL functions or aggregates 2128** or to redefine the behavior of existing SQL functions or aggregates. The 2129** difference only between the two is that the second parameter, the 2130** name of the (scalar) function or aggregate, is encoded in UTF-8 for 2131** sqlite3_create_function() and UTF-16 for sqlite3_create_function16(). 2132** 2133** The first argument is the [sqlite3 | database handle] that holds the 2134** SQL function or aggregate is to be added or redefined. If a single 2135** program uses more than one database handle internally, then SQL 2136** functions or aggregates must be added individually to each database 2137** handle with which they will be used. 2138** 2139** The second parameter is the name of the SQL function to be created 2140** or redefined. 2141** The length of the name is limited to 255 bytes, exclusive of the 2142** zero-terminator. Note that the name length limit is in bytes, not 2143** characters. Any attempt to create a function with a longer name 2144** will result in an SQLITE_ERROR error. 2145** 2146** The third parameter is the number of arguments that the SQL function or 2147** aggregate takes. If this parameter is negative, then the SQL function or 2148** aggregate may take any number of arguments. 2149** 2150** The fourth parameter, eTextRep, specifies what 2151** [SQLITE_UTF8 | text encoding] this SQL function prefers for 2152** its parameters. Any SQL function implementation should be able to work 2153** work with UTF-8, UTF-16le, or UTF-16be. But some implementations may be 2154** more efficient with one encoding than another. It is allowed to 2155** invoke sqlite3_create_function() or sqlite3_create_function16() multiple 2156** times with the same function but with different values of eTextRep. 2157** When multiple implementations of the same function are available, SQLite 2158** will pick the one that involves the least amount of data conversion. 2159** If there is only a single implementation which does not care what 2160** text encoding is used, then the fourth argument should be 2161** [SQLITE_ANY]. 2162** 2163** The fifth parameter is an arbitrary pointer. The implementation 2164** of the function can gain access to this pointer using 2165** [sqlite3_user_data()]. 2166** 2167** The seventh, eighth and ninth parameters, xFunc, xStep and xFinal, are 2168** pointers to C-language functions that implement the SQL 2169** function or aggregate. A scalar SQL function requires an implementation of 2170** the xFunc callback only, NULL pointers should be passed as the xStep 2171** and xFinal parameters. An aggregate SQL function requires an implementation 2172** of xStep and xFinal and NULL should be passed for xFunc. To delete an 2173** existing SQL function or aggregate, pass NULL for all three function 2174** callback. 2175** 2176** It is permitted to register multiple implementations of the same 2177** functions with the same name but with either differing numbers of 2178** arguments or differing perferred text encodings. SQLite will use 2179** the implementation most closely matches the way in which the 2180** SQL function is used. 2181*/ 2182int sqlite3_create_function( 2183 sqlite3 *, 2184 const char *zFunctionName, 2185 int nArg, 2186 int eTextRep, 2187 void*, 2188 void (*xFunc)(sqlite3_context*,int,sqlite3_value**), 2189 void (*xStep)(sqlite3_context*,int,sqlite3_value**), 2190 void (*xFinal)(sqlite3_context*) 2191); 2192int sqlite3_create_function16( 2193 sqlite3*, 2194 const void *zFunctionName, 2195 int nArg, 2196 int eTextRep, 2197 void*, 2198 void (*xFunc)(sqlite3_context*,int,sqlite3_value**), 2199 void (*xStep)(sqlite3_context*,int,sqlite3_value**), 2200 void (*xFinal)(sqlite3_context*) 2201); 2202 2203/* 2204** CAPI3REF: Text Encodings 2205** 2206** These constant define integer codes that represent the various 2207** text encodings supported by SQLite. 2208*/ 2209#define SQLITE_UTF8 1 2210#define SQLITE_UTF16LE 2 2211#define SQLITE_UTF16BE 3 2212#define SQLITE_UTF16 4 /* Use native byte order */ 2213#define SQLITE_ANY 5 /* sqlite3_create_function only */ 2214#define SQLITE_UTF16_ALIGNED 8 /* sqlite3_create_collation only */ 2215 2216/* 2217** CAPI3REF: Obsolete Functions 2218** 2219** These functions are all now obsolete. In order to maintain 2220** backwards compatibility with older code, we continue to support 2221** these functions. However, new development projects should avoid 2222** the use of these functions. To help encourage people to avoid 2223** using these functions, we are not going to tell you want they do. 2224*/ 2225int sqlite3_aggregate_count(sqlite3_context*); 2226int sqlite3_expired(sqlite3_stmt*); 2227int sqlite3_transfer_bindings(sqlite3_stmt*, sqlite3_stmt*); 2228int sqlite3_global_recover(void); 2229void sqlite3_thread_cleanup(void); 2230 2231/* 2232** CAPI3REF: Obtaining SQL Function Parameter Values 2233** 2234** The C-language implementation of SQL functions and aggregates uses 2235** this set of interface routines to access the parameter values on 2236** the function or aggregate. 2237** 2238** The xFunc (for scalar functions) or xStep (for aggregates) parameters 2239** to [sqlite3_create_function()] and [sqlite3_create_function16()] 2240** define callbacks that implement the SQL functions and aggregates. 2241** The 4th parameter to these callbacks is an array of pointers to 2242** [sqlite3_value] objects. There is one [sqlite3_value] object for 2243** each parameter to the SQL function. These routines are used to 2244** extract values from the [sqlite3_value] objects. 2245** 2246** These routines work just like the corresponding 2247** [sqlite3_column_blob | sqlite3_column_* routines] except that 2248** these routines take a single [sqlite3_value*] pointer instead 2249** of an [sqlite3_stmt*] pointer and an integer column number. 2250** 2251** The sqlite3_value_text16() interface extracts a UTF16 string 2252** in the native byte-order of the host machine. The 2253** sqlite3_value_text16be() and sqlite3_value_text16le() interfaces 2254** extract UTF16 strings as big-endian and little-endian respectively. 2255** 2256** The sqlite3_value_numeric_type() interface attempts to apply 2257** numeric affinity to the value. This means that an attempt is 2258** made to convert the value to an integer or floating point. If 2259** such a conversion is possible without loss of information (in order 2260** words if the value is original a string that looks like a number) 2261** then it is done. Otherwise no conversion occurs. The 2262** [SQLITE_INTEGER | datatype] after conversion is returned. 2263** 2264** Please pay particular attention to the fact that the pointer that 2265** is returned from [sqlite3_value_blob()], [sqlite3_value_text()], or 2266** [sqlite3_value_text16()] can be invalidated by a subsequent call to 2267** [sqlite3_value_bytes()], [sqlite3_value_bytes16()], [sqlite3_value_text()], 2268** or [sqlite3_value_text16()]. 2269** 2270** These routines must be called from the same thread as 2271** the SQL function that supplied the sqlite3_value* parameters. 2272** Or, if the sqlite3_value* argument comes from the [sqlite3_column_value()] 2273** interface, then these routines should be called from the same thread 2274** that ran [sqlite3_column_value()]. 2275*/ 2276const void *sqlite3_value_blob(sqlite3_value*); 2277int sqlite3_value_bytes(sqlite3_value*); 2278int sqlite3_value_bytes16(sqlite3_value*); 2279double sqlite3_value_double(sqlite3_value*); 2280int sqlite3_value_int(sqlite3_value*); 2281sqlite3_int64 sqlite3_value_int64(sqlite3_value*); 2282const unsigned char *sqlite3_value_text(sqlite3_value*); 2283const void *sqlite3_value_text16(sqlite3_value*); 2284const void *sqlite3_value_text16le(sqlite3_value*); 2285const void *sqlite3_value_text16be(sqlite3_value*); 2286int sqlite3_value_type(sqlite3_value*); 2287int sqlite3_value_numeric_type(sqlite3_value*); 2288 2289/* 2290** CAPI3REF: Obtain Aggregate Function Context 2291** 2292** The implementation of aggregate SQL functions use this routine to allocate 2293** a structure for storing their state. The first time this routine 2294** is called for a particular aggregate, a new structure of size nBytes 2295** is allocated, zeroed, and returned. On subsequent calls (for the 2296** same aggregate instance) the same buffer is returned. The implementation 2297** of the aggregate can use the returned buffer to accumulate data. 2298** 2299** The buffer allocated is freed automatically by SQLite whan the aggregate 2300** query concludes. 2301** 2302** The first parameter should be a copy of the 2303** [sqlite3_context | SQL function context] that is the first 2304** parameter to the callback routine that implements the aggregate 2305** function. 2306** 2307** This routine must be called from the same thread in which 2308** the aggregate SQL function is running. 2309*/ 2310void *sqlite3_aggregate_context(sqlite3_context*, int nBytes); 2311 2312/* 2313** CAPI3REF: User Data For Functions 2314** 2315** The pUserData parameter to the [sqlite3_create_function()] 2316** and [sqlite3_create_function16()] routines 2317** used to register user functions is available to 2318** the implementation of the function using this call. 2319** 2320** This routine must be called from the same thread in which 2321** the SQL function is running. 2322*/ 2323void *sqlite3_user_data(sqlite3_context*); 2324 2325/* 2326** CAPI3REF: Function Auxiliary Data 2327** 2328** The following two functions may be used by scalar SQL functions to 2329** associate meta-data with argument values. If the same value is passed to 2330** multiple invocations of the same SQL function during query execution, under 2331** some circumstances the associated meta-data may be preserved. This may 2332** be used, for example, to add a regular-expression matching scalar 2333** function. The compiled version of the regular expression is stored as 2334** meta-data associated with the SQL value passed as the regular expression 2335** pattern. The compiled regular expression can be reused on multiple 2336** invocations of the same function so that the original pattern string 2337** does not need to be recompiled on each invocation. 2338** 2339** The sqlite3_get_auxdata() interface returns a pointer to the meta-data 2340** associated with the Nth argument value to the current SQL function 2341** call, where N is the second parameter. If no meta-data has been set for 2342** that value, then a NULL pointer is returned. 2343** 2344** The sqlite3_set_auxdata() is used to associate meta-data with an SQL 2345** function argument. The third parameter is a pointer to the meta-data 2346** to be associated with the Nth user function argument value. The fourth 2347** parameter specifies a destructor that will be called on the meta- 2348** data pointer to release it when it is no longer required. If the 2349** destructor is NULL, it is not invoked. 2350** 2351** In practice, meta-data is preserved between function calls for 2352** expressions that are constant at compile time. This includes literal 2353** values and SQL variables. 2354** 2355** These routines must be called from the same thread in which 2356** the SQL function is running. 2357*/ 2358void *sqlite3_get_auxdata(sqlite3_context*, int); 2359void sqlite3_set_auxdata(sqlite3_context*, int, void*, void (*)(void*)); 2360 2361 2362/* 2363** CAPI3REF: Constants Defining Special Destructor Behavior 2364** 2365** These are special value for the destructor that is passed in as the 2366** final argument to routines like [sqlite3_result_blob()]. If the destructor 2367** argument is SQLITE_STATIC, it means that the content pointer is constant 2368** and will never change. It does not need to be destroyed. The 2369** SQLITE_TRANSIENT value means that the content will likely change in 2370** the near future and that SQLite should make its own private copy of 2371** the content before returning. 2372** 2373** The typedef is necessary to work around problems in certain 2374** C++ compilers. See ticket #2191. 2375*/ 2376typedef void (*sqlite3_destructor_type)(void*); 2377#define SQLITE_STATIC ((sqlite3_destructor_type)0) 2378#define SQLITE_TRANSIENT ((sqlite3_destructor_type)-1) 2379 2380/* 2381** CAPI3REF: Setting The Result Of An SQL Function 2382** 2383** These routines are used by the xFunc or xFinal callbacks that 2384** implement SQL functions and aggregates. See 2385** [sqlite3_create_function()] and [sqlite3_create_function16()] 2386** for additional information. 2387** 2388** These functions work very much like the 2389** [sqlite3_bind_blob | sqlite3_bind_*] family of functions used 2390** to bind values to host parameters in prepared statements. 2391** Refer to the 2392** [sqlite3_bind_blob | sqlite3_bind_* documentation] for 2393** additional information. 2394** 2395** The sqlite3_result_error() and sqlite3_result_error16() functions 2396** cause the implemented SQL function to throw an exception. The 2397** parameter to sqlite3_result_error() or sqlite3_result_error16() 2398** is the text of an error message. 2399** 2400** The sqlite3_result_toobig() cause the function implementation 2401** to throw and error indicating that a string or BLOB is to long 2402** to represent. 2403** 2404** These routines must be called from within the same thread as 2405** the SQL function associated with the [sqlite3_context] pointer. 2406*/ 2407void sqlite3_result_blob(sqlite3_context*, const void*, int, void(*)(void*)); 2408void sqlite3_result_double(sqlite3_context*, double); 2409void sqlite3_result_error(sqlite3_context*, const char*, int); 2410void sqlite3_result_error16(sqlite3_context*, const void*, int); 2411void sqlite3_result_error_toobig(sqlite3_context*); 2412void sqlite3_result_error_nomem(sqlite3_context*); 2413void sqlite3_result_int(sqlite3_context*, int); 2414void sqlite3_result_int64(sqlite3_context*, sqlite3_int64); 2415void sqlite3_result_null(sqlite3_context*); 2416void sqlite3_result_text(sqlite3_context*, const char*, int, void(*)(void*)); 2417void sqlite3_result_text16(sqlite3_context*, const void*, int, void(*)(void*)); 2418void sqlite3_result_text16le(sqlite3_context*, const void*, int,void(*)(void*)); 2419void sqlite3_result_text16be(sqlite3_context*, const void*, int,void(*)(void*)); 2420void sqlite3_result_value(sqlite3_context*, sqlite3_value*); 2421void sqlite3_result_zeroblob(sqlite3_context*, int n); 2422 2423/* 2424** CAPI3REF: Define New Collating Sequences 2425** 2426** These functions are used to add new collation sequences to the 2427** [sqlite3*] handle specified as the first argument. 2428** 2429** The name of the new collation sequence is specified as a UTF-8 string 2430** for sqlite3_create_collation() and sqlite3_create_collation_v2() 2431** and a UTF-16 string for sqlite3_create_collation16(). In all cases 2432** the name is passed as the second function argument. 2433** 2434** The third argument must be one of the constants [SQLITE_UTF8], 2435** [SQLITE_UTF16LE] or [SQLITE_UTF16BE], indicating that the user-supplied 2436** routine expects to be passed pointers to strings encoded using UTF-8, 2437** UTF-16 little-endian or UTF-16 big-endian respectively. 2438** 2439** A pointer to the user supplied routine must be passed as the fifth 2440** argument. If it is NULL, this is the same as deleting the collation 2441** sequence (so that SQLite cannot call it anymore). Each time the user 2442** supplied function is invoked, it is passed a copy of the void* passed as 2443** the fourth argument to sqlite3_create_collation() or 2444** sqlite3_create_collation16() as its first parameter. 2445** 2446** The remaining arguments to the user-supplied routine are two strings, 2447** each represented by a [length, data] pair and encoded in the encoding 2448** that was passed as the third argument when the collation sequence was 2449** registered. The user routine should return negative, zero or positive if 2450** the first string is less than, equal to, or greater than the second 2451** string. i.e. (STRING1 - STRING2). 2452** 2453** The sqlite3_create_collation_v2() works like sqlite3_create_collation() 2454** excapt that it takes an extra argument which is a destructor for 2455** the collation. The destructor is called when the collation is 2456** destroyed and is passed a copy of the fourth parameter void* pointer 2457** of the sqlite3_create_collation_v2(). Collations are destroyed when 2458** they are overridden by later calls to the collation creation functions 2459** or when the [sqlite3*] database handle is closed using [sqlite3_close()]. 2460** 2461** The sqlite3_create_collation_v2() interface is experimental and 2462** subject to change in future releases. The other collation creation 2463** functions are stable. 2464*/ 2465int sqlite3_create_collation( 2466 sqlite3*, 2467 const char *zName, 2468 int eTextRep, 2469 void*, 2470 int(*xCompare)(void*,int,const void*,int,const void*) 2471); 2472int sqlite3_create_collation_v2( 2473 sqlite3*, 2474 const char *zName, 2475 int eTextRep, 2476 void*, 2477 int(*xCompare)(void*,int,const void*,int,const void*), 2478 void(*xDestroy)(void*) 2479); 2480int sqlite3_create_collation16( 2481 sqlite3*, 2482 const char *zName, 2483 int eTextRep, 2484 void*, 2485 int(*xCompare)(void*,int,const void*,int,const void*) 2486); 2487 2488/* 2489** CAPI3REF: Collation Needed Callbacks 2490** 2491** To avoid having to register all collation sequences before a database 2492** can be used, a single callback function may be registered with the 2493** database handle to be called whenever an undefined collation sequence is 2494** required. 2495** 2496** If the function is registered using the sqlite3_collation_needed() API, 2497** then it is passed the names of undefined collation sequences as strings 2498** encoded in UTF-8. If sqlite3_collation_needed16() is used, the names 2499** are passed as UTF-16 in machine native byte order. A call to either 2500** function replaces any existing callback. 2501** 2502** When the callback is invoked, the first argument passed is a copy 2503** of the second argument to sqlite3_collation_needed() or 2504** sqlite3_collation_needed16(). The second argument is the database 2505** handle. The third argument is one of [SQLITE_UTF8], [SQLITE_UTF16BE], or 2506** [SQLITE_UTF16LE], indicating the most desirable form of the collation 2507** sequence function required. The fourth parameter is the name of the 2508** required collation sequence. 2509** 2510** The callback function should register the desired collation using 2511** [sqlite3_create_collation()], [sqlite3_create_collation16()], or 2512** [sqlite3_create_collation_v2()]. 2513*/ 2514int sqlite3_collation_needed( 2515 sqlite3*, 2516 void*, 2517 void(*)(void*,sqlite3*,int eTextRep,const char*) 2518); 2519int sqlite3_collation_needed16( 2520 sqlite3*, 2521 void*, 2522 void(*)(void*,sqlite3*,int eTextRep,const void*) 2523); 2524 2525/* 2526** Specify the key for an encrypted database. This routine should be 2527** called right after sqlite3_open(). 2528** 2529** The code to implement this API is not available in the public release 2530** of SQLite. 2531*/ 2532int sqlite3_key( 2533 sqlite3 *db, /* Database to be rekeyed */ 2534 const void *pKey, int nKey /* The key */ 2535); 2536 2537/* 2538** Change the key on an open database. If the current database is not 2539** encrypted, this routine will encrypt it. If pNew==0 or nNew==0, the 2540** database is decrypted. 2541** 2542** The code to implement this API is not available in the public release 2543** of SQLite. 2544*/ 2545int sqlite3_rekey( 2546 sqlite3 *db, /* Database to be rekeyed */ 2547 const void *pKey, int nKey /* The new key */ 2548); 2549 2550/* 2551** CAPI3REF: Suspend Execution For A Short Time 2552** 2553** This function causes the current thread to suspend execution 2554** a number of milliseconds specified in its parameter. 2555** 2556** If the operating system does not support sleep requests with 2557** millisecond time resolution, then the time will be rounded up to 2558** the nearest second. The number of milliseconds of sleep actually 2559** requested from the operating system is returned. 2560** 2561** SQLite implements this interface by calling the xSleep() 2562** method of the default [sqlite3_vfs] object. 2563*/ 2564int sqlite3_sleep(int); 2565 2566/* 2567** CAPI3REF: Name Of The Folder Holding Temporary Files 2568** 2569** If this global variable is made to point to a string which is 2570** the name of a folder (a.ka. directory), then all temporary files 2571** created by SQLite will be placed in that directory. If this variable 2572** is NULL pointer, then SQLite does a search for an appropriate temporary 2573** file directory. 2574** 2575** Once [sqlite3_open()] has been called, changing this variable will 2576** invalidate the current temporary database, if any. Generally speaking, 2577** it is not safe to invoke this routine after [sqlite3_open()] has 2578** been called. 2579*/ 2580SQLITE_EXTERN char *sqlite3_temp_directory; 2581 2582/* 2583** CAPI3REF: Test To See If The Databse Is In Auto-Commit Mode 2584** 2585** Test to see whether or not the database connection is in autocommit 2586** mode. Return TRUE if it is and FALSE if not. Autocommit mode is on 2587** by default. Autocommit is disabled by a BEGIN statement and reenabled 2588** by the next COMMIT or ROLLBACK. 2589** 2590** If another thread changes the autocommit status of the database 2591** connection while this routine is running, then the return value 2592** is undefined. 2593*/ 2594int sqlite3_get_autocommit(sqlite3*); 2595 2596/* 2597** CAPI3REF: Find The Database Handle Associated With A Prepared Statement 2598** 2599** Return the [sqlite3*] database handle to which a 2600** [sqlite3_stmt | prepared statement] belongs. 2601** This is the same database handle that was 2602** the first argument to the [sqlite3_prepare_v2()] or its variants 2603** that was used to create the statement in the first place. 2604*/ 2605sqlite3 *sqlite3_db_handle(sqlite3_stmt*); 2606 2607 2608/* 2609** CAPI3REF: Commit And Rollback Notification Callbacks 2610** 2611** These routines 2612** register callback functions to be invoked whenever a transaction 2613** is committed or rolled back. The pArg argument is passed through 2614** to the callback. If the callback on a commit hook function 2615** returns non-zero, then the commit is converted into a rollback. 2616** 2617** If another function was previously registered, its pArg value is returned. 2618** Otherwise NULL is returned. 2619** 2620** Registering a NULL function disables the callback. 2621** 2622** For the purposes of this API, a transaction is said to have been 2623** rolled back if an explicit "ROLLBACK" statement is executed, or 2624** an error or constraint causes an implicit rollback to occur. The 2625** callback is not invoked if a transaction is automatically rolled 2626** back because the database connection is closed. 2627** 2628** These are experimental interfaces and are subject to change. 2629*/ 2630void *sqlite3_commit_hook(sqlite3*, int(*)(void*), void*); 2631void *sqlite3_rollback_hook(sqlite3*, void(*)(void *), void*); 2632 2633/* 2634** CAPI3REF: Data Change Notification Callbacks 2635** 2636** Register a callback function with the database connection identified by the 2637** first argument to be invoked whenever a row is updated, inserted or deleted. 2638** Any callback set by a previous call to this function for the same 2639** database connection is overridden. 2640** 2641** The second argument is a pointer to the function to invoke when a 2642** row is updated, inserted or deleted. The first argument to the callback is 2643** a copy of the third argument to sqlite3_update_hook(). The second callback 2644** argument is one of SQLITE_INSERT, SQLITE_DELETE or SQLITE_UPDATE, depending 2645** on the operation that caused the callback to be invoked. The third and 2646** fourth arguments to the callback contain pointers to the database and 2647** table name containing the affected row. The final callback parameter is 2648** the rowid of the row. In the case of an update, this is the rowid after 2649** the update takes place. 2650** 2651** The update hook is not invoked when internal system tables are 2652** modified (i.e. sqlite_master and sqlite_sequence). 2653** 2654** If another function was previously registered, its pArg value is returned. 2655** Otherwise NULL is returned. 2656*/ 2657void *sqlite3_update_hook( 2658 sqlite3*, 2659 void(*)(void *,int ,char const *,char const *,sqlite3_int64), 2660 void* 2661); 2662 2663/* 2664** CAPI3REF: Enable Or Disable Shared Pager Cache 2665** 2666** This routine enables or disables the sharing of the database cache 2667** and schema data structures between connections to the same database. 2668** Sharing is enabled if the argument is true and disabled if the argument 2669** is false. 2670** 2671** Beginning in SQLite version 3.5.0, cache sharing is enabled and disabled 2672** for an entire process. In prior versions of SQLite, sharing was 2673** enabled or disabled for each thread separately. 2674** 2675** The cache sharing mode set by this interface effects all subsequent 2676** calls to [sqlite3_open()], [sqlite3_open_v2()], and [sqlite3_open16()]. 2677** Existing database connections continue use the sharing mode that was 2678** in effect at the time they were opened. 2679** 2680** Virtual tables cannot be used with a shared cache. When shared 2681** cache is enabled, the sqlite3_create_module() API used to register 2682** virtual tables will always return an error. 2683** 2684** This routine returns [SQLITE_OK] if shared cache was 2685** enabled or disabled successfully. An [SQLITE_ERROR | error code] 2686** is returned otherwise. 2687** 2688** Shared cache is disabled by default for backward compatibility. 2689*/ 2690int sqlite3_enable_shared_cache(int); 2691 2692/* 2693** CAPI3REF: Attempt To Free Heap Memory 2694** 2695** Attempt to free N bytes of heap memory by deallocating non-essential 2696** memory allocations held by the database library (example: memory 2697** used to cache database pages to improve performance). 2698** 2699** This function is not a part of standard builds. It is only created 2700** if SQLite is compiled with the SQLITE_ENABLE_MEMORY_MANAGEMENT macro. 2701*/ 2702int sqlite3_release_memory(int); 2703 2704/* 2705** CAPI3REF: Impose A Limit On Heap Size 2706** 2707** Place a "soft" limit on the amount of heap memory that may be allocated 2708** by SQLite. If an internal allocation is requested 2709** that would exceed the specified limit, [sqlite3_release_memory()] is 2710** invoked one or more times to free up some space before the allocation 2711** is made. 2712** 2713** The limit is called "soft", because if [sqlite3_release_memory()] cannot 2714** free sufficient memory to prevent the limit from being exceeded, 2715** the memory is allocated anyway and the current operation proceeds. 2716** 2717** A negative or zero value for N means that there is no soft heap limit and 2718** [sqlite3_release_memory()] will only be called when memory is exhausted. 2719** The default value for the soft heap limit is zero. 2720** 2721** SQLite makes a best effort to honor the soft heap limit. But if it 2722** is unable to reduce memory usage below the soft limit, execution will 2723** continue without error or notification. This is why the limit is 2724** called a "soft" limit. It is advisory only. 2725** 2726** The soft heap limit is implemented using the [sqlite3_memory_alarm()] 2727** interface. Only a single memory alarm is available in the default 2728** implementation. This means that if the application also uses the 2729** memory alarm interface it will interfere with the operation of the 2730** soft heap limit and undefined behavior will result. 2731** 2732** Prior to SQLite version 3.5.0, this routine only constrained the memory 2733** allocated by a single thread - the same thread in which this routine 2734** runs. Beginning with SQLite version 3.5.0, the soft heap limit is 2735** applied to all threads. The value specified for the soft heap limit 2736** is an bound on the total memory allocation for all threads. In 2737** version 3.5.0 there is no mechanism for limiting the heap usage for 2738** individual threads. 2739*/ 2740void sqlite3_soft_heap_limit(int); 2741 2742/* 2743** CAPI3REF: Extract Metadata About A Column Of A Table 2744** 2745** This routine 2746** returns meta-data about a specific column of a specific database 2747** table accessible using the connection handle passed as the first function 2748** argument. 2749** 2750** The column is identified by the second, third and fourth parameters to 2751** this function. The second parameter is either the name of the database 2752** (i.e. "main", "temp" or an attached database) containing the specified 2753** table or NULL. If it is NULL, then all attached databases are searched 2754** for the table using the same algorithm as the database engine uses to 2755** resolve unqualified table references. 2756** 2757** The third and fourth parameters to this function are the table and column 2758** name of the desired column, respectively. Neither of these parameters 2759** may be NULL. 2760** 2761** Meta information is returned by writing to the memory locations passed as 2762** the 5th and subsequent parameters to this function. Any of these 2763** arguments may be NULL, in which case the corresponding element of meta 2764** information is ommitted. 2765** 2766** <pre> 2767** Parameter Output Type Description 2768** ----------------------------------- 2769** 2770** 5th const char* Data type 2771** 6th const char* Name of the default collation sequence 2772** 7th int True if the column has a NOT NULL constraint 2773** 8th int True if the column is part of the PRIMARY KEY 2774** 9th int True if the column is AUTOINCREMENT 2775** </pre> 2776** 2777** 2778** The memory pointed to by the character pointers returned for the 2779** declaration type and collation sequence is valid only until the next 2780** call to any sqlite API function. 2781** 2782** If the specified table is actually a view, then an error is returned. 2783** 2784** If the specified column is "rowid", "oid" or "_rowid_" and an 2785** INTEGER PRIMARY KEY column has been explicitly declared, then the output 2786** parameters are set for the explicitly declared column. If there is no 2787** explicitly declared IPK column, then the output parameters are set as 2788** follows: 2789** 2790** <pre> 2791** data type: "INTEGER" 2792** collation sequence: "BINARY" 2793** not null: 0 2794** primary key: 1 2795** auto increment: 0 2796** </pre> 2797** 2798** This function may load one or more schemas from database files. If an 2799** error occurs during this process, or if the requested table or column 2800** cannot be found, an SQLITE error code is returned and an error message 2801** left in the database handle (to be retrieved using sqlite3_errmsg()). 2802** 2803** This API is only available if the library was compiled with the 2804** SQLITE_ENABLE_COLUMN_METADATA preprocessor symbol defined. 2805*/ 2806int sqlite3_table_column_metadata( 2807 sqlite3 *db, /* Connection handle */ 2808 const char *zDbName, /* Database name or NULL */ 2809 const char *zTableName, /* Table name */ 2810 const char *zColumnName, /* Column name */ 2811 char const **pzDataType, /* OUTPUT: Declared data type */ 2812 char const **pzCollSeq, /* OUTPUT: Collation sequence name */ 2813 int *pNotNull, /* OUTPUT: True if NOT NULL constraint exists */ 2814 int *pPrimaryKey, /* OUTPUT: True if column part of PK */ 2815 int *pAutoinc /* OUTPUT: True if colums is auto-increment */ 2816); 2817 2818/* 2819** CAPI3REF: Load An Extension 2820** 2821** Attempt to load an SQLite extension library contained in the file 2822** zFile. The entry point is zProc. zProc may be 0 in which case the 2823** name of the entry point defaults to "sqlite3_extension_init". 2824** 2825** Return [SQLITE_OK] on success and [SQLITE_ERROR] if something goes wrong. 2826** 2827** If an error occurs and pzErrMsg is not 0, then fill *pzErrMsg with 2828** error message text. The calling function should free this memory 2829** by calling [sqlite3_free()]. 2830** 2831** Extension loading must be enabled using [sqlite3_enable_load_extension()] 2832** prior to calling this API or an error will be returned. 2833*/ 2834int sqlite3_load_extension( 2835 sqlite3 *db, /* Load the extension into this database connection */ 2836 const char *zFile, /* Name of the shared library containing extension */ 2837 const char *zProc, /* Entry point. Derived from zFile if 0 */ 2838 char **pzErrMsg /* Put error message here if not 0 */ 2839); 2840 2841/* 2842** CAPI3REF: Enable Or Disable Extension Loading 2843** 2844** So as not to open security holes in older applications that are 2845** unprepared to deal with extension loading, and as a means of disabling 2846** extension loading while evaluating user-entered SQL, the following 2847** API is provided to turn the [sqlite3_load_extension()] mechanism on and 2848** off. It is off by default. See ticket #1863. 2849** 2850** Call this routine with onoff==1 to turn extension loading on 2851** and call it with onoff==0 to turn it back off again. 2852*/ 2853int sqlite3_enable_load_extension(sqlite3 *db, int onoff); 2854 2855/* 2856** CAPI3REF: Make Arrangements To Automatically Load An Extension 2857** 2858** Register an extension entry point that is automatically invoked 2859** whenever a new database connection is opened using 2860** [sqlite3_open()], [sqlite3_open16()], or [sqlite3_open_v2()]. 2861** 2862** This API can be invoked at program startup in order to register 2863** one or more statically linked extensions that will be available 2864** to all new database connections. 2865** 2866** Duplicate extensions are detected so calling this routine multiple 2867** times with the same extension is harmless. 2868** 2869** This routine stores a pointer to the extension in an array 2870** that is obtained from malloc(). If you run a memory leak 2871** checker on your program and it reports a leak because of this 2872** array, then invoke [sqlite3_automatic_extension_reset()] prior 2873** to shutdown to free the memory. 2874** 2875** Automatic extensions apply across all threads. 2876** 2877** This interface is experimental and is subject to change or 2878** removal in future releases of SQLite. 2879*/ 2880int sqlite3_auto_extension(void *xEntryPoint); 2881 2882 2883/* 2884** CAPI3REF: Reset Automatic Extension Loading 2885** 2886** Disable all previously registered automatic extensions. This 2887** routine undoes the effect of all prior [sqlite3_automatic_extension()] 2888** calls. 2889** 2890** This call disabled automatic extensions in all threads. 2891** 2892** This interface is experimental and is subject to change or 2893** removal in future releases of SQLite. 2894*/ 2895void sqlite3_reset_auto_extension(void); 2896 2897 2898/* 2899****** EXPERIMENTAL - subject to change without notice ************** 2900** 2901** The interface to the virtual-table mechanism is currently considered 2902** to be experimental. The interface might change in incompatible ways. 2903** If this is a problem for you, do not use the interface at this time. 2904** 2905** When the virtual-table mechanism stablizes, we will declare the 2906** interface fixed, support it indefinitely, and remove this comment. 2907*/ 2908 2909/* 2910** Structures used by the virtual table interface 2911*/ 2912typedef struct sqlite3_vtab sqlite3_vtab; 2913typedef struct sqlite3_index_info sqlite3_index_info; 2914typedef struct sqlite3_vtab_cursor sqlite3_vtab_cursor; 2915typedef struct sqlite3_module sqlite3_module; 2916 2917/* 2918** A module is a class of virtual tables. Each module is defined 2919** by an instance of the following structure. This structure consists 2920** mostly of methods for the module. 2921*/ 2922struct sqlite3_module { 2923 int iVersion; 2924 int (*xCreate)(sqlite3*, void *pAux, 2925 int argc, const char *const*argv, 2926 sqlite3_vtab **ppVTab, char**); 2927 int (*xConnect)(sqlite3*, void *pAux, 2928 int argc, const char *const*argv, 2929 sqlite3_vtab **ppVTab, char**); 2930 int (*xBestIndex)(sqlite3_vtab *pVTab, sqlite3_index_info*); 2931 int (*xDisconnect)(sqlite3_vtab *pVTab); 2932 int (*xDestroy)(sqlite3_vtab *pVTab); 2933 int (*xOpen)(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor); 2934 int (*xClose)(sqlite3_vtab_cursor*); 2935 int (*xFilter)(sqlite3_vtab_cursor*, int idxNum, const char *idxStr, 2936 int argc, sqlite3_value **argv); 2937 int (*xNext)(sqlite3_vtab_cursor*); 2938 int (*xEof)(sqlite3_vtab_cursor*); 2939 int (*xColumn)(sqlite3_vtab_cursor*, sqlite3_context*, int); 2940 int (*xRowid)(sqlite3_vtab_cursor*, sqlite3_int64 *pRowid); 2941 int (*xUpdate)(sqlite3_vtab *, int, sqlite3_value **, sqlite3_int64 *); 2942 int (*xBegin)(sqlite3_vtab *pVTab); 2943 int (*xSync)(sqlite3_vtab *pVTab); 2944 int (*xCommit)(sqlite3_vtab *pVTab); 2945 int (*xRollback)(sqlite3_vtab *pVTab); 2946 int (*xFindFunction)(sqlite3_vtab *pVtab, int nArg, const char *zName, 2947 void (**pxFunc)(sqlite3_context*,int,sqlite3_value**), 2948 void **ppArg); 2949 2950 int (*xRename)(sqlite3_vtab *pVtab, const char *zNew); 2951}; 2952 2953/* 2954** The sqlite3_index_info structure and its substructures is used to 2955** pass information into and receive the reply from the xBestIndex 2956** method of an sqlite3_module. The fields under **Inputs** are the 2957** inputs to xBestIndex and are read-only. xBestIndex inserts its 2958** results into the **Outputs** fields. 2959** 2960** The aConstraint[] array records WHERE clause constraints of the 2961** form: 2962** 2963** column OP expr 2964** 2965** Where OP is =, <, <=, >, or >=. The particular operator is stored 2966** in aConstraint[].op. The index of the column is stored in 2967** aConstraint[].iColumn. aConstraint[].usable is TRUE if the 2968** expr on the right-hand side can be evaluated (and thus the constraint 2969** is usable) and false if it cannot. 2970** 2971** The optimizer automatically inverts terms of the form "expr OP column" 2972** and makes other simplificatinos to the WHERE clause in an attempt to 2973** get as many WHERE clause terms into the form shown above as possible. 2974** The aConstraint[] array only reports WHERE clause terms in the correct 2975** form that refer to the particular virtual table being queried. 2976** 2977** Information about the ORDER BY clause is stored in aOrderBy[]. 2978** Each term of aOrderBy records a column of the ORDER BY clause. 2979** 2980** The xBestIndex method must fill aConstraintUsage[] with information 2981** about what parameters to pass to xFilter. If argvIndex>0 then 2982** the right-hand side of the corresponding aConstraint[] is evaluated 2983** and becomes the argvIndex-th entry in argv. If aConstraintUsage[].omit 2984** is true, then the constraint is assumed to be fully handled by the 2985** virtual table and is not checked again by SQLite. 2986** 2987** The idxNum and idxPtr values are recorded and passed into xFilter. 2988** sqlite3_free() is used to free idxPtr if needToFreeIdxPtr is true. 2989** 2990** The orderByConsumed means that output from xFilter will occur in 2991** the correct order to satisfy the ORDER BY clause so that no separate 2992** sorting step is required. 2993** 2994** The estimatedCost value is an estimate of the cost of doing the 2995** particular lookup. A full scan of a table with N entries should have 2996** a cost of N. A binary search of a table of N entries should have a 2997** cost of approximately log(N). 2998*/ 2999struct sqlite3_index_info { 3000 /* Inputs */ 3001 const int nConstraint; /* Number of entries in aConstraint */ 3002 const struct sqlite3_index_constraint { 3003 int iColumn; /* Column on left-hand side of constraint */ 3004 unsigned char op; /* Constraint operator */ 3005 unsigned char usable; /* True if this constraint is usable */ 3006 int iTermOffset; /* Used internally - xBestIndex should ignore */ 3007 } *const aConstraint; /* Table of WHERE clause constraints */ 3008 const int nOrderBy; /* Number of terms in the ORDER BY clause */ 3009 const struct sqlite3_index_orderby { 3010 int iColumn; /* Column number */ 3011 unsigned char desc; /* True for DESC. False for ASC. */ 3012 } *const aOrderBy; /* The ORDER BY clause */ 3013 3014 /* Outputs */ 3015 struct sqlite3_index_constraint_usage { 3016 int argvIndex; /* if >0, constraint is part of argv to xFilter */ 3017 unsigned char omit; /* Do not code a test for this constraint */ 3018 } *const aConstraintUsage; 3019 int idxNum; /* Number used to identify the index */ 3020 char *idxStr; /* String, possibly obtained from sqlite3_malloc */ 3021 int needToFreeIdxStr; /* Free idxStr using sqlite3_free() if true */ 3022 int orderByConsumed; /* True if output is already ordered */ 3023 double estimatedCost; /* Estimated cost of using this index */ 3024}; 3025#define SQLITE_INDEX_CONSTRAINT_EQ 2 3026#define SQLITE_INDEX_CONSTRAINT_GT 4 3027#define SQLITE_INDEX_CONSTRAINT_LE 8 3028#define SQLITE_INDEX_CONSTRAINT_LT 16 3029#define SQLITE_INDEX_CONSTRAINT_GE 32 3030#define SQLITE_INDEX_CONSTRAINT_MATCH 64 3031 3032/* 3033** This routine is used to register a new module name with an SQLite 3034** connection. Module names must be registered before creating new 3035** virtual tables on the module, or before using preexisting virtual 3036** tables of the module. 3037*/ 3038int sqlite3_create_module( 3039 sqlite3 *db, /* SQLite connection to register module with */ 3040 const char *zName, /* Name of the module */ 3041 const sqlite3_module *, /* Methods for the module */ 3042 void * /* Client data for xCreate/xConnect */ 3043); 3044 3045/* 3046** This routine is identical to the sqlite3_create_module() method above, 3047** except that it allows a destructor function to be specified. It is 3048** even more experimental than the rest of the virtual tables API. 3049*/ 3050int sqlite3_create_module_v2( 3051 sqlite3 *db, /* SQLite connection to register module with */ 3052 const char *zName, /* Name of the module */ 3053 const sqlite3_module *, /* Methods for the module */ 3054 void *, /* Client data for xCreate/xConnect */ 3055 void(*xDestroy)(void*) /* Module destructor function */ 3056); 3057 3058/* 3059** Every module implementation uses a subclass of the following structure 3060** to describe a particular instance of the module. Each subclass will 3061** be taylored to the specific needs of the module implementation. The 3062** purpose of this superclass is to define certain fields that are common 3063** to all module implementations. 3064** 3065** Virtual tables methods can set an error message by assigning a 3066** string obtained from sqlite3_mprintf() to zErrMsg. The method should 3067** take care that any prior string is freed by a call to sqlite3_free() 3068** prior to assigning a new string to zErrMsg. After the error message 3069** is delivered up to the client application, the string will be automatically 3070** freed by sqlite3_free() and the zErrMsg field will be zeroed. Note 3071** that sqlite3_mprintf() and sqlite3_free() are used on the zErrMsg field 3072** since virtual tables are commonly implemented in loadable extensions which 3073** do not have access to sqlite3MPrintf() or sqlite3Free(). 3074*/ 3075struct sqlite3_vtab { 3076 const sqlite3_module *pModule; /* The module for this virtual table */ 3077 int nRef; /* Used internally */ 3078 char *zErrMsg; /* Error message from sqlite3_mprintf() */ 3079 /* Virtual table implementations will typically add additional fields */ 3080}; 3081 3082/* Every module implementation uses a subclass of the following structure 3083** to describe cursors that point into the virtual table and are used 3084** to loop through the virtual table. Cursors are created using the 3085** xOpen method of the module. Each module implementation will define 3086** the content of a cursor structure to suit its own needs. 3087** 3088** This superclass exists in order to define fields of the cursor that 3089** are common to all implementations. 3090*/ 3091struct sqlite3_vtab_cursor { 3092 sqlite3_vtab *pVtab; /* Virtual table of this cursor */ 3093 /* Virtual table implementations will typically add additional fields */ 3094}; 3095 3096/* 3097** The xCreate and xConnect methods of a module use the following API 3098** to declare the format (the names and datatypes of the columns) of 3099** the virtual tables they implement. 3100*/ 3101int sqlite3_declare_vtab(sqlite3*, const char *zCreateTable); 3102 3103/* 3104** Virtual tables can provide alternative implementations of functions 3105** using the xFindFunction method. But global versions of those functions 3106** must exist in order to be overloaded. 3107** 3108** This API makes sure a global version of a function with a particular 3109** name and number of parameters exists. If no such function exists 3110** before this API is called, a new function is created. The implementation 3111** of the new function always causes an exception to be thrown. So 3112** the new function is not good for anything by itself. Its only 3113** purpose is to be a place-holder function that can be overloaded 3114** by virtual tables. 3115** 3116** This API should be considered part of the virtual table interface, 3117** which is experimental and subject to change. 3118*/ 3119int sqlite3_overload_function(sqlite3*, const char *zFuncName, int nArg); 3120 3121/* 3122** The interface to the virtual-table mechanism defined above (back up 3123** to a comment remarkably similar to this one) is currently considered 3124** to be experimental. The interface might change in incompatible ways. 3125** If this is a problem for you, do not use the interface at this time. 3126** 3127** When the virtual-table mechanism stablizes, we will declare the 3128** interface fixed, support it indefinitely, and remove this comment. 3129** 3130****** EXPERIMENTAL - subject to change without notice ************** 3131*/ 3132 3133/* 3134** CAPI3REF: A Handle To An Open BLOB 3135** 3136** An instance of the following opaque structure is used to 3137** represent an blob-handle. A blob-handle is created by 3138** [sqlite3_blob_open()] and destroyed by [sqlite3_blob_close()]. 3139** The [sqlite3_blob_read()] and [sqlite3_blob_write()] interfaces 3140** can be used to read or write small subsections of the blob. 3141** The [sqltie3_blob_size()] interface returns the size of the 3142** blob in bytes. 3143*/ 3144typedef struct sqlite3_blob sqlite3_blob; 3145 3146/* 3147** CAPI3REF: Open A BLOB For Incremental I/O 3148** 3149** Open a handle to the blob located in row iRow,, column zColumn, 3150** table zTable in database zDb. i.e. the same blob that would 3151** be selected by: 3152** 3153** <pre> 3154** SELECT zColumn FROM zDb.zTable WHERE rowid = iRow; 3155** </pre> 3156** 3157** If the flags parameter is non-zero, the blob is opened for 3158** read and write access. If it is zero, the blob is opened for read 3159** access. 3160** 3161** On success, [SQLITE_OK] is returned and the new 3162** [sqlite3_blob | blob handle] is written to *ppBlob. 3163** Otherwise an error code is returned and 3164** any value written to *ppBlob should not be used by the caller. 3165** This function sets the database-handle error code and message 3166** accessible via [sqlite3_errcode()] and [sqlite3_errmsg()]. 3167*/ 3168int sqlite3_blob_open( 3169 sqlite3*, 3170 const char *zDb, 3171 const char *zTable, 3172 const char *zColumn, 3173 sqlite3_int64 iRow, 3174 int flags, 3175 sqlite3_blob **ppBlob 3176); 3177 3178/* 3179** CAPI3REF: Close A BLOB Handle 3180** 3181** Close an open [sqlite3_blob | blob handle]. 3182*/ 3183int sqlite3_blob_close(sqlite3_blob *); 3184 3185/* 3186** CAPI3REF: Return The Size Of An Open BLOB 3187** 3188** Return the size in bytes of the blob accessible via the open 3189** [sqlite3_blob | blob-handle] passed as an argument. 3190*/ 3191int sqlite3_blob_bytes(sqlite3_blob *); 3192 3193/* 3194** CAPI3REF: Read Data From A BLOB Incrementally 3195** 3196** This function is used to read data from an open 3197** [sqlite3_blob | blob-handle] into a caller supplied buffer. 3198** n bytes of data are copied into buffer 3199** z from the open blob, starting at offset iOffset. 3200** 3201** On success, SQLITE_OK is returned. Otherwise, an 3202** [SQLITE_ERROR | SQLite error code] or an 3203** [SQLITE_IOERR_READ | extended error code] is returned. 3204*/ 3205int sqlite3_blob_read(sqlite3_blob *, void *z, int n, int iOffset); 3206 3207/* 3208** CAPI3REF: Write Data Into A BLOB Incrementally 3209** 3210** This function is used to write data into an open 3211** [sqlite3_blob | blob-handle] from a user supplied buffer. 3212** n bytes of data are copied from the buffer 3213** pointed to by z into the open blob, starting at offset iOffset. 3214** 3215** If the [sqlite3_blob | blob-handle] passed as the first argument 3216** was not opened for writing (the flags parameter to [sqlite3_blob_open()] 3217*** was zero), this function returns [SQLITE_READONLY]. 3218** 3219** This function may only modify the contents of the blob, it is 3220** not possible to increase the size of a blob using this API. If 3221** offset iOffset is less than n bytes from the end of the blob, 3222** [SQLITE_ERROR] is returned and no data is written. 3223** 3224** On success, SQLITE_OK is returned. Otherwise, an 3225** [SQLITE_ERROR | SQLite error code] or an 3226** [SQLITE_IOERR_READ | extended error code] is returned. 3227*/ 3228int sqlite3_blob_write(sqlite3_blob *, const void *z, int n, int iOffset); 3229 3230/* 3231** CAPI3REF: Virtual File System Objects 3232** 3233** A virtual filesystem (VFS) is an [sqlite3_vfs] object 3234** that SQLite uses to interact 3235** with the underlying operating system. Most builds come with a 3236** single default VFS that is appropriate for the host computer. 3237** New VFSes can be registered and existing VFSes can be unregistered. 3238** The following interfaces are provided. 3239** 3240** The sqlite3_vfs_find() interface returns a pointer to a VFS given its 3241** name. Names are case sensitive. If there is no match, a NULL 3242** pointer is returned. If zVfsName is NULL then the default 3243** VFS is returned. 3244** 3245** New VFSes are registered with sqlite3_vfs_register(). Each 3246** new VFS becomes the default VFS if the makeDflt flag is set. 3247** The same VFS can be registered multiple times without injury. 3248** To make an existing VFS into the default VFS, register it again 3249** with the makeDflt flag set. If two different VFSes with the 3250** same name are registered, the behavior is undefined. If a 3251** VFS is registered with a name that is NULL or an empty string, 3252** then the behavior is undefined. 3253** 3254** Unregister a VFS with the sqlite3_vfs_unregister() interface. 3255** If the default VFS is unregistered, another VFS is chosen as 3256** the default. The choice for the new VFS is arbitrary. 3257*/ 3258sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName); 3259int sqlite3_vfs_register(sqlite3_vfs*, int makeDflt); 3260int sqlite3_vfs_unregister(sqlite3_vfs*); 3261 3262/* 3263** CAPI3REF: Mutexes 3264** 3265** The SQLite core uses these routines for thread 3266** synchronization. Though they are intended for internal 3267** use by SQLite, code that links against SQLite is 3268** permitted to use any of these routines. 3269** 3270** The SQLite source code contains multiple implementations 3271** of these mutex routines. An appropriate implementation 3272** is selected automatically at compile-time. The following 3273** implementations are available in the SQLite core: 3274** 3275** <ul> 3276** <li> SQLITE_MUTEX_OS2 3277** <li> SQLITE_MUTEX_PTHREAD 3278** <li> SQLITE_MUTEX_W32 3279** <li> SQLITE_MUTEX_NOOP 3280** </ul> 3281** 3282** The SQLITE_MUTEX_NOOP implementation is a set of routines 3283** that does no real locking and is appropriate for use in 3284** a single-threaded application. The SQLITE_MUTEX_OS2, 3285** SQLITE_MUTEX_PTHREAD, and SQLITE_MUTEX_W32 implementations 3286** are appropriate for use on os/2, unix, and windows. 3287** 3288** If SQLite is compiled with the SQLITE_MUTEX_APPDEF preprocessor 3289** macro defined (with "-DSQLITE_MUTEX_APPDEF=1"), then no mutex 3290** implementation is included with the library. The 3291** mutex interface routines defined here become external 3292** references in the SQLite library for which implementations 3293** must be provided by the application. This facility allows an 3294** application that links against SQLite to provide its own mutex 3295** implementation without having to modify the SQLite core. 3296** 3297** The sqlite3_mutex_alloc() routine allocates a new 3298** mutex and returns a pointer to it. If it returns NULL 3299** that means that a mutex could not be allocated. SQLite 3300** will unwind its stack and return an error. The argument 3301** to sqlite3_mutex_alloc() is one of these integer constants: 3302** 3303** <ul> 3304** <li> SQLITE_MUTEX_FAST 3305** <li> SQLITE_MUTEX_RECURSIVE 3306** <li> SQLITE_MUTEX_STATIC_MASTER 3307** <li> SQLITE_MUTEX_STATIC_MEM 3308** <li> SQLITE_MUTEX_STATIC_MEM2 3309** <li> SQLITE_MUTEX_STATIC_PRNG 3310** <li> SQLITE_MUTEX_STATIC_LRU 3311** </ul> 3312** 3313** The first two constants cause sqlite3_mutex_alloc() to create 3314** a new mutex. The new mutex is recursive when SQLITE_MUTEX_RECURSIVE 3315** is used but not necessarily so when SQLITE_MUTEX_FAST is used. 3316** The mutex implementation does not need to make a distinction 3317** between SQLITE_MUTEX_RECURSIVE and SQLITE_MUTEX_FAST if it does 3318** not want to. But SQLite will only request a recursive mutex in 3319** cases where it really needs one. If a faster non-recursive mutex 3320** implementation is available on the host platform, the mutex subsystem 3321** might return such a mutex in response to SQLITE_MUTEX_FAST. 3322** 3323** The other allowed parameters to sqlite3_mutex_alloc() each return 3324** a pointer to a static preexisting mutex. Four static mutexes are 3325** used by the current version of SQLite. Future versions of SQLite 3326** may add additional static mutexes. Static mutexes are for internal 3327** use by SQLite only. Applications that use SQLite mutexes should 3328** use only the dynamic mutexes returned by SQLITE_MUTEX_FAST or 3329** SQLITE_MUTEX_RECURSIVE. 3330** 3331** Note that if one of the dynamic mutex parameters (SQLITE_MUTEX_FAST 3332** or SQLITE_MUTEX_RECURSIVE) is used then sqlite3_mutex_alloc() 3333** returns a different mutex on every call. But for the static 3334** mutex types, the same mutex is returned on every call that has 3335** the same type number. 3336** 3337** The sqlite3_mutex_free() routine deallocates a previously 3338** allocated dynamic mutex. SQLite is careful to deallocate every 3339** dynamic mutex that it allocates. The dynamic mutexes must not be in 3340** use when they are deallocated. Attempting to deallocate a static 3341** mutex results in undefined behavior. SQLite never deallocates 3342** a static mutex. 3343** 3344** The sqlite3_mutex_enter() and sqlite3_mutex_try() routines attempt 3345** to enter a mutex. If another thread is already within the mutex, 3346** sqlite3_mutex_enter() will block and sqlite3_mutex_try() will return 3347** SQLITE_BUSY. The sqlite3_mutex_try() interface returns SQLITE_OK 3348** upon successful entry. Mutexes created using SQLITE_MUTEX_RECURSIVE can 3349** be entered multiple times by the same thread. In such cases the, 3350** mutex must be exited an equal number of times before another thread 3351** can enter. If the same thread tries to enter any other kind of mutex 3352** more than once, the behavior is undefined. SQLite will never exhibit 3353** such behavior in its own use of mutexes. 3354** 3355** The sqlite3_mutex_leave() routine exits a mutex that was 3356** previously entered by the same thread. The behavior 3357** is undefined if the mutex is not currently entered by the 3358** calling thread or is not currently allocated. SQLite will 3359** never do either. 3360** 3361** See also: [sqlite3_mutex_held()] and [sqlite3_mutex_notheld()]. 3362*/ 3363sqlite3_mutex *sqlite3_mutex_alloc(int); 3364void sqlite3_mutex_free(sqlite3_mutex*); 3365void sqlite3_mutex_enter(sqlite3_mutex*); 3366int sqlite3_mutex_try(sqlite3_mutex*); 3367void sqlite3_mutex_leave(sqlite3_mutex*); 3368 3369/* 3370** CAPI3REF: Mutex Verifcation Routines 3371** 3372** The sqlite3_mutex_held() and sqlite3_mutex_notheld() routines 3373** are intended for use inside assert() statements. The SQLite core 3374** never uses these routines except inside an assert() and applications 3375** are advised to follow the lead of the core. The core only 3376** provides implementations for these routines when it is compiled 3377** with the SQLITE_DEBUG flag. External mutex implementations 3378** are only required to provide these routines if SQLITE_DEBUG is 3379** defined and if NDEBUG is not defined. 3380** 3381** These routines should return true if the mutex in their argument 3382** is held or not held, respectively, by the calling thread. 3383** 3384** The implementation is not required to provided versions of these 3385** routines that actually work. 3386** If the implementation does not provide working 3387** versions of these routines, it should at least provide stubs 3388** that always return true so that one does not get spurious 3389** assertion failures. 3390** 3391** If the argument to sqlite3_mutex_held() is a NULL pointer then 3392** the routine should return 1. This seems counter-intuitive since 3393** clearly the mutex cannot be held if it does not exist. But the 3394** the reason the mutex does not exist is because the build is not 3395** using mutexes. And we do not want the assert() containing the 3396** call to sqlite3_mutex_held() to fail, so a non-zero return is 3397** the appropriate thing to do. The sqlite3_mutex_notheld() 3398** interface should also return 1 when given a NULL pointer. 3399*/ 3400int sqlite3_mutex_held(sqlite3_mutex*); 3401int sqlite3_mutex_notheld(sqlite3_mutex*); 3402 3403/* 3404** CAPI3REF: Mutex Types 3405** 3406** The [sqlite3_mutex_alloc()] interface takes a single argument 3407** which is one of these integer constants. 3408*/ 3409#define SQLITE_MUTEX_FAST 0 3410#define SQLITE_MUTEX_RECURSIVE 1 3411#define SQLITE_MUTEX_STATIC_MASTER 2 3412#define SQLITE_MUTEX_STATIC_MEM 3 /* sqlite3_malloc() */ 3413#define SQLITE_MUTEX_STATIC_MEM2 4 /* sqlite3_release_memory() */ 3414#define SQLITE_MUTEX_STATIC_PRNG 5 /* sqlite3_random() */ 3415#define SQLITE_MUTEX_STATIC_LRU 6 /* lru page list */ 3416 3417 3418/* 3419** Undo the hack that converts floating point types to integer for 3420** builds on processors without floating point support. 3421*/ 3422#ifdef SQLITE_OMIT_FLOATING_POINT 3423# undef double 3424#endif 3425 3426#ifdef __cplusplus 3427} /* End of the 'extern "C"' block */ 3428#endif 3429#endif 3430