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