root/trunk/Frameworks/sqlite3.h
| Revision 3755, 114.7 kB (checked in by timothy, 1 year ago) |
|---|
| Line | |
|---|---|
| 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.212 2007/06/14 20:57:19 drh Exp $ |
| 34 | */ |
| 35 | #ifndef _SQLITE3_H_ |
| 36 | #define _SQLITE3_H_ |
| 37 | #include <stdarg.h> /* Needed for the definition of va_list */ |
| 38 | |
| 39 | /* |
| 40 | ** Make sure we can call this stuff from C++. |
| 41 | */ |
| 42 | #ifdef __cplusplus |
| 43 | extern "C" { |
| 44 | #endif |
| 45 | |
| 46 | /* |
| 47 | ** Make sure these symbols where not defined by some previous header |
| 48 | ** file. |
| 49 | */ |
| 50 | #ifdef SQLITE_VERSION |
| 51 | # undef SQLITE_VERSION |
| 52 | #endif |
| 53 | #ifdef SQLITE_VERSION_NUMBER |
| 54 | # undef SQLITE_VERSION_NUMBER |
| 55 | #endif |
| 56 | |
| 57 | /* |
| 58 | ** CAPI3REF: Compile-Time Library Version Numbers |
| 59 | ** |
| 60 | ** The version of the SQLite library is contained in the sqlite3.h |
| 61 | ** header file in a #define named SQLITE_VERSION. The SQLITE_VERSION |
| 62 | ** macro resolves to a string constant. |
| 63 | ** |
| 64 | ** The format of the version string is "X.Y.Z", where |
| 65 | ** X is the major version number, Y is the minor version number and Z |
| 66 | ** is the release number. The X.Y.Z might be followed by "alpha" or "beta". |
| 67 | ** For example "3.1.1beta". |
| 68 | ** |
| 69 | ** The X value is always 3 in SQLite. The X value only changes when |
| 70 | ** backwards compatibility is broken and we intend to never break |
| 71 | ** backwards compatibility. The Y value only changes when |
| 72 | ** there are major feature enhancements that are forwards compatible |
| 73 | ** but not backwards compatible. The Z value is incremented with |
| 74 | ** each release but resets back to 0 when Y is incremented. |
| 75 | ** |
| 76 | ** The SQLITE_VERSION_NUMBER is an integer with the value |
| 77 | ** (X*1000000 + Y*1000 + Z). For example, for version "3.1.1beta", |
| 78 | ** SQLITE_VERSION_NUMBER is set to 3001001. To detect if they are using |
| 79 | ** version 3.1.1 or greater at compile time, programs may use the test |
| 80 | ** (SQLITE_VERSION_NUMBER>=3001001). |
| 81 | ** |
| 82 | ** See also: [sqlite3_libversion()] and [sqlite3_libversion_number()]. |
| 83 | */ |
| 84 | #define SQLITE_VERSION "3.4.0" |
| 85 | #define SQLITE_VERSION_NUMBER 3004000 |
| 86 | |
| 87 | /* |
| 88 | ** CAPI3REF: Run-Time Library Version Numbers |
| 89 | ** |
| 90 | ** These routines return values equivalent to the header constants |
| 91 | ** [SQLITE_VERSION] and [SQLITE_VERSION_NUMBER]. The values returned |
| 92 | ** by this routines should only be different from the header values |
| 93 | ** if you compile your program using an sqlite3.h header from a |
| 94 | ** different version of SQLite that the version of the library you |
| 95 | ** link against. |
| 96 | ** |
| 97 | ** The sqlite3_version[] string constant contains the text of the |
| 98 | ** [SQLITE_VERSION] string. The sqlite3_libversion() function returns |
| 99 | ** a poiner to the sqlite3_version[] string constant. The function |
| 100 | ** is provided for DLL users who can only access functions and not |
| 101 | ** constants within the DLL. |
| 102 | */ |
| 103 | extern const char sqlite3_version[]; |
| 104 | const char *sqlite3_libversion(void); |
| 105 | int sqlite3_libversion_number(void); |
| 106 | |
| 107 | /* |
| 108 | ** CAPI3REF: Database Connection Handle |
| 109 | ** |
| 110 | ** Each open SQLite database is represented by pointer to an instance of the |
| 111 | ** opaque structure named "sqlite3". It is useful to think of an sqlite3 |
| 112 | ** pointer as an object. The [sqlite3_open] interface is its constructor |
| 113 | ** and [sqlite3_close] is its destructor. There are many other interfaces |
| 114 | ** (such as [sqlite3_prepare_v2], [sqlite3_create_function], and |
| 115 | ** [sqlite3_busy_timeout] to name but three) that are methods on this |
| 116 | ** object. |
| 117 | */ |
| 118 | typedef struct sqlite3 sqlite3; |
| 119 | |
| 120 | |
| 121 | /* |
| 122 | ** CAPI3REF: 64-Bit Integer Types |
| 123 | ** |
| 124 | ** Some compilers do not support the "long long" datatype. So we have |
| 125 | ** to do compiler-specific typedefs for 64-bit signed and unsigned integers. |
| 126 | ** |
| 127 | ** Many SQLite interface functions require a 64-bit integer arguments. |
| 128 | ** Those interfaces are declared using this typedef. |
| 129 | */ |
| 130 | #ifdef SQLITE_INT64_TYPE |
| 131 | typedef SQLITE_INT64_TYPE sqlite_int64; |
| 132 | typedef unsigned SQLITE_INT64_TYPE sqlite_uint64; |
| 133 | #elif defined(_MSC_VER) || defined(__BORLANDC__) |
| 134 | typedef __int64 sqlite_int64; |
| 135 | typedef unsigned __int64 sqlite_uint64; |
| 136 | #else |
| 137 | typedef long long int sqlite_int64; |
| 138 | typedef unsigned long long int sqlite_uint64; |
| 139 | #endif |
| 140 | |
| 141 | /* |
| 142 | ** If compiling for a processor that lacks floating point support, |
| 143 | ** substitute integer for floating-point |
| 144 | */ |
| 145 | #ifdef SQLITE_OMIT_FLOATING_POINT |
| 146 | # define double sqlite_int64 |
| 147 | #endif |
| 148 | |
| 149 | /* |
| 150 | ** CAPI3REF: Closing A Database Connection |
| 151 | ** |
| 152 | ** Call this function with a pointer to a structure that was previously |
| 153 | ** returned from [sqlite3_open()] and the corresponding database will by |
| 154 | ** closed. |
| 155 | ** |
| 156 | ** All SQL statements prepared using [sqlite3_prepare_v2()] or |
| 157 | ** [sqlite3_prepare16_v2()] must be destroyed using [sqlite3_finalize()] |
| 158 | ** before this routine is called. Otherwise, SQLITE_BUSY is returned and the |
| 159 | ** database connection remains open. |
| 160 | */ |
| 161 | int sqlite3_close(sqlite3 *); |
| 162 | |
| 163 | /* |
| 164 | ** The type for a callback function. |
| 165 | ** This is legacy and deprecated. It is included for historical |
| 166 | ** compatibility and is not documented. |
| 167 | */ |
| 168 | typedef int (*sqlite3_callback)(void*,int,char**, char**); |
| 169 | |
| 170 | /* |
| 171 | ** CAPI3REF: One-Step Query Execution Interface |
| 172 | ** |
| 173 | ** This interface is used to do a one-time evaluatation of zero |
| 174 | ** or more SQL statements. UTF-8 text of the SQL statements to |
| 175 | ** be evaluted is passed in as the second parameter. The statements |
| 176 | ** are prepared one by one using [sqlite3_prepare()], evaluated |
| 177 | ** using [sqlite3_step()], then destroyed using [sqlite3_finalize()]. |
| 178 | ** |
| 179 | ** If one or more of the SQL statements are queries, then |
| 180 | ** the callback function specified by the 3rd parameter is |
| 181 | ** invoked once for each row of the query result. This callback |
| 182 | ** should normally return 0. If the callback returns a non-zero |
| 183 | ** value then the query is aborted, all subsequent SQL statements |
| 184 | ** are skipped and the sqlite3_exec() function returns the SQLITE_ABORT. |
| 185 | ** |
| 186 | ** The 4th parameter to this interface is an arbitrary pointer that is |
| 187 | ** passed through to the callback function as its first parameter. |
| 188 | ** |
| 189 | ** The 2nd parameter to the callback function is the number of |
| 190 | ** columns in the query result. The 3rd parameter to the callback |
| 191 | ** is an array of strings holding the values for each column |
| 192 | ** as extracted using [sqlite3_column_text()]. |
| 193 | ** The 4th parameter to the callback is an array of strings |
| 194 | ** obtained using [sqlite3_column_name()] and holding |
| 195 | ** the names of each column. |
| 196 | ** |
| 197 | ** The callback function may be NULL, even for queries. A NULL |
| 198 | ** callback is not an error. It just means that no callback |
| 199 | ** will be invoked. |
| 200 | ** |
| 201 | ** If an error occurs while parsing or evaluating the SQL (but |
| 202 | ** not while executing the callback) then an appropriate error |
| 203 | ** message is written into memory obtained from [sqlite3_malloc()] and |
| 204 | ** *errmsg is made to point to that message. The calling function |
| 205 | ** is responsible for freeing the memory that holds the error |
| 206 | ** message. Use [sqlite3_free()] for this. If errmsg==NULL, |
| 207 | ** then no error message is ever written. |
| 208 | ** |
| 209 | ** The return value is is SQLITE_OK if there are no errors and |
| 210 | ** some other [SQLITE_OK | return code] if there is an error. |
| 211 | ** The particular return value depends on the type of error. |
| 212 | ** |
| 213 | */ |
| 214 | int sqlite3_exec( |
| 215 | sqlite3*, /* An open database */ |
| 216 | const char *sql, /* SQL to be evaluted */ |
| 217 | int (*callback)(void*,int,char**,char**), /* Callback function */ |
| 218 | void *, /* 1st argument to callback */ |
| 219 | char **errmsg /* Error msg written here */ |
| 220 | ); |
| 221 | |
| 222 | /* |
| 223 | ** CAPI3REF: Result Codes |
| 224 | ** KEYWORDS: SQLITE_OK |
| 225 | ** |
| 226 | ** Many SQLite functions return an integer result code from the set shown |
| 227 | ** above in order to indicates success or failure. |
| 228 | ** |
| 229 | ** The result codes above are the only ones returned by SQLite in its |
| 230 | ** default configuration. However, the [sqlite3_extended_result_codes()] |
| 231 | ** API can be used to set a database connectoin to return more detailed |
| 232 | ** result codes. |
| 233 | ** |
| 234 | ** See also: [SQLITE_IOERR_READ | extended result codes] |
| 235 | ** |
| 236 | */ |
| 237 | #define SQLITE_OK 0 /* Successful result */ |
| 238 | /* beginning-of-error-codes */ |
| 239 | #define SQLITE_ERROR 1 /* SQL error or missing database */ |
| 240 | #define SQLITE_INTERNAL 2 /* NOT USED. Internal logic error in SQLite */ |
| 241 | #define SQLITE_PERM 3 /* Access permission denied */ |
| 242 | #define SQLITE_ABORT 4 /* Callback routine requested an abort */ |
| 243 | #define SQLITE_BUSY 5 /* The database file is locked */ |
| 244 | #define SQLITE_LOCKED 6 /* A table in the database is locked */ |
| 245 | #define SQLITE_NOMEM 7 /* A malloc() failed */ |
| 246 | #define SQLITE_READONLY 8 /* Attempt to write a readonly database */ |
| 247 | #define SQLITE_INTERRUPT 9 /* Operation terminated by sqlite3_interrupt()*/ |
| 248 | #define SQLITE_IOERR 10 /* Some kind of disk I/O error occurred */ |
| 249 | #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ |
| 250 | #define SQLITE_NOTFOUND 12 /* NOT USED. Table or record not found */ |
| 251 | #define SQLITE_FULL 13 /* Insertion failed because database is full */ |
| 252 | #define SQLITE_CANTOPEN 14 /* Unable to open the database file */ |
| 253 | #define SQLITE_PROTOCOL 15 /* NOT USED. Database lock protocol error */ |
| 254 | #define SQLITE_EMPTY 16 /* Database is empty */ |
| 255 | #define SQLITE_SCHEMA 17 /* The database schema changed */ |
| 256 | #define SQLITE_TOOBIG 18 /* String or BLOB exceeds size limit */ |
| 257 | #define SQLITE_CONSTRAINT 19 /* Abort due to contraint violation */ |
| 258 | #define SQLITE_MISMATCH 20 /* Data type mismatch */ |
| 259 | #define SQLITE_MISUSE 21 /* Library used incorrectly */ |
| 260 | #define SQLITE_NOLFS 22 /* Uses OS features not supported on host */ |
| 261 | #define SQLITE_AUTH 23 /* Authorization denied */ |
| 262 | #define SQLITE_FORMAT 24 /* Auxiliary database format error */ |
| 263 | #define SQLITE_RANGE 25 /* 2nd parameter to sqlite3_bind out of range */ |
| 264 | #define SQLITE_NOTADB 26 /* File opened that is not a database file */ |
| 265 | #define SQLITE_ROW 100 /* sqlite3_step() has another row ready */ |
| 266 | #define SQLITE_DONE 101 /* sqlite3_step() has finished executing */ |
| 267 | /* end-of-error-codes */ |
| 268 | |
| 269 | /* |
| 270 | ** CAPI3REF: Extended Result Codes |
| 271 | ** |
| 272 | ** In its default configuration, SQLite API routines return one of 26 integer |
| 273 | ** result codes described at result-codes. However, experience has shown that |
| 274 | ** many of these result codes are too course-grained. They do not provide as |
| 275 | ** much information about problems as users might like. In an effort to |
| 276 | ** address this, newer versions of SQLite (version 3.3.8 and later) include |
| 277 | ** support for additional result codes that provide more detailed information |
| 278 | ** about errors. The extended result codes are enabled (or disabled) for |
| 279 | ** each database |
| 280 | ** connection using the [sqlite3_extended_result_codes()] API. |
| 281 | ** |
| 282 | ** Some of the available extended result codes are listed above. |
| 283 | ** We expect the number of extended result codes will be expand |
| 284 | ** over time. Software that uses extended result codes should expect |
| 285 | ** to see new result codes in future releases of SQLite. |
| 286 | ** |
| 287 | ** The symbolic name for an extended result code always contains a related |
| 288 | ** primary result code as a prefix. Primary result codes contain a single |
| 289 | ** "_" character. Extended result codes contain two or more "_" characters. |
| 290 | ** The numeric value of an extended result code can be converted to its |
| 291 | ** corresponding primary result code by masking off the lower 8 bytes. |
| 292 | ** |
| 293 | ** The SQLITE_OK result code will never be extended. It will always |
| 294 | ** be exactly zero. |
| 295 | */ |
| 296 | #define SQLITE_IOERR_READ (SQLITE_IOERR | (1<<8)) |
| 297 | #define SQLITE_IOERR_SHORT_READ (SQLITE_IOERR | (2<<8)) |
| 298 | #define SQLITE_IOERR_WRITE (SQLITE_IOERR | (3<<8)) |
| 299 | #define SQLITE_IOERR_FSYNC (SQLITE_IOERR | (4<<8)) |
| 300 | #define SQLITE_IOERR_DIR_FSYNC (SQLITE_IOERR | (5<<8)) |
| 301 | #define SQLITE_IOERR_TRUNCATE (SQLITE_IOERR | (6<<8)) |
| 302 | #define SQLITE_IOERR_FSTAT (SQLITE_IOERR | (7<<8)) |
| 303 | #define SQLITE_IOERR_UNLOCK (SQLITE_IOERR | (8<<8)) |
| 304 | #define SQLITE_IOERR_RDLOCK (SQLITE_IOERR | (9<<8)) |
| 305 | #define SQLITE_IOERR_DELETE (SQLITE_IOERR | (10<<8)) |
| 306 | #define SQLITE_IOERR_BLOCKED (SQLITE_IOERR | (11<<8)) |
| 307 | |
| 308 | /* |
| 309 | ** CAPI3REF: Enable Or Disable Extended Result Codes |
| 310 | ** |
| 311 | ** This routine enables or disables the |
| 312 | ** [SQLITE_IOERR_READ | extended result codes] feature. |
| 313 | ** By default, SQLite API routines return one of only 26 integer |
| 314 | ** [SQLITE_OK | result codes]. When extended result codes |
| 315 | ** are enabled by this routine, the repetoire of result codes can be |
| 316 | ** much larger and can (hopefully) provide more detailed information |
| 317 | ** about the cause of an error. |
| 318 | ** |
| 319 | ** The second argument is a boolean value that turns extended result |
| 320 | ** codes on and off. Extended result codes are off by default for |
| 321 | ** backwards compatibility with older versions of SQLite. |
| 322 | */ |
| 323 | int sqlite3_extended_result_codes(sqlite3*, int onoff); |
| 324 | |
| 325 | /* |
| 326 | ** CAPI3REF: Last Insert Rowid |
| 327 | ** |
| 328 | ** Each entry in an SQLite table has a unique 64-bit signed integer key |
| 329 | ** called the "rowid". The rowid is always available as an undeclared |
| 330 | ** column named ROWID, OID, or _ROWID_. If the table has a column of |
| 331 | ** type INTEGER PRIMARY KEY then that column is another an alias for the |
| 332 | ** rowid. |
| 333 | ** |
| 334 | ** This routine returns the rowid of the most recent INSERT into |
| 335 | ** the database from the database connection given in the first |
| 336 | ** argument. If no inserts have ever occurred on this database |
| 337 | ** connection, zero is returned. |
| 338 | ** |
| 339 | ** If an INSERT occurs within a trigger, then the rowid of the |
| 340 | ** inserted row is returned by this routine as long as the trigger |
| 341 | ** is running. But once the trigger terminates, the value returned |
| 342 | ** by this routine reverts to the last value inserted before the |
| 343 | ** trigger fired. |
| 344 | */ |
| 345 | sqlite_int64 sqlite3_last_insert_rowid(sqlite3*); |
| 346 | |
| 347 | /* |
| 348 | ** CAPI3REF: Count The Number Of Rows Modified |
| 349 | ** |
| 350 | ** This function returns the number of database rows that were changed |
| 351 | ** (or inserted or deleted) by the most recent SQL statement. Only |
| 352 | ** changes that are directly specified by the INSERT, UPDATE, or |
| 353 | ** DELETE statement are counted. Auxiliary changes caused by |
| 354 | ** triggers are not counted. Use the [sqlite3_total_changes()] function |
| 355 | ** to find the total number of changes including changes caused by triggers. |
| 356 | ** |
| 357 | ** Within the body of a trigger, the sqlite3_changes() interface can be |
| 358 | ** called to find the number of |
| 359 | ** changes in the most recently completed INSERT, UPDATE, or DELETE |
| 360 | ** statement within the body of the trigger. |
| 361 | ** |
| 362 | ** All changes are counted, even if they were later undone by a |
| 363 | ** ROLLBACK or ABORT. Except, changes associated with creating and |
| 364 | ** dropping tables are not counted. |
| 365 | ** |
| 366 | ** If a callback invokes [sqlite3_exec()] or [sqlite3_step()] recursively, |
| 367 | ** then the changes in the inner, recursive call are counted together |
| 368 | ** with the changes in the outer call. |
| 369 | ** |
| 370 | ** SQLite implements the command "DELETE FROM table" without a WHERE clause |
| 371 | ** by dropping and recreating the table. (This is much faster than going |
| 372 | ** through and deleting individual elements form the table.) Because of |
| 373 | ** this optimization, the change count for "DELETE FROM table" will be |
| 374 | ** zero regardless of the number of elements that were originally in the |
| 375 | ** table. To get an accurate count of the number of rows deleted, use |
| 376 | ** "DELETE FROM table WHERE 1" instead. |
| 377 | */ |
| 378 | int sqlite3_changes(sqlite3*); |
| 379 | |
| 380 | /* |
| 381 | ** CAPI3REF: Total Number Of Rows Modified |
| 382 | *** |
| 383 | ** This function returns the number of database rows that have been |
| 384 | ** modified by INSERT, UPDATE or DELETE statements since the database handle |
| 385 | ** was opened. This includes UPDATE, INSERT and DELETE statements executed |
| 386 | ** as part of trigger programs. All changes are counted as soon as the |
| 387 | ** statement that makes them is completed (when the statement handle is |
| 388 | ** passed to [sqlite3_reset()] or [sqlite_finalise()]). |
| 389 | ** |
| 390 | ** See also the [sqlite3_change()] interface. |
| 391 | ** |
| 392 | ** SQLite implements the command "DELETE FROM table" without a WHERE clause |
| 393 | ** by dropping and recreating the table. (This is much faster than going |
| 394 | ** through and deleting individual elements form the table.) Because of |
| 395 | ** this optimization, the change count for "DELETE FROM table" will be |
| 396 | ** zero regardless of the number of elements that were originally in the |
| 397 | ** table. To get an accurate count of the number of rows deleted, use |
| 398 | ** "DELETE FROM table WHERE 1" instead. |
| 399 | */ |
| 400 | int sqlite3_total_changes(sqlite3*); |
| 401 | |
| 402 | /* |
| 403 | ** CAPI3REF: Interrupt A Long-Running Query |
| 404 | ** |
| 405 | ** This function causes any pending database operation to abort and |
| 406 | ** return at its earliest opportunity. This routine is typically |
| 407 | ** called in response to a user action such as pressing "Cancel" |
| 408 | ** or Ctrl-C where the user wants a long query operation to halt |
| 409 | ** immediately. |
| 410 | ** |
| 411 | ** It is safe to call this routine from a thread different from the |
| 412 | ** thread that is currently running the database operation. |
| 413 | ** |
| 414 | ** The SQL operation that is interrupted will return [SQLITE_INTERRUPT]. |
| 415 | ** If an interrupted operation was an update that is inside an |
| 416 | ** explicit transaction, then the entire transaction will be rolled |
| 417 | ** back automatically. |
| 418 | */ |
| 419 | void sqlite3_interrupt(sqlite3*); |
| 420 | |
| 421 | /* |
| 422 | ** CAPI3REF: Determine If An SQL Statement Is Complete |
| 423 | ** |
| 424 | ** These functions return true if the given input string comprises |
| 425 | ** one or more complete SQL statements. For the sqlite3_complete() call, |
| 426 | ** the parameter must be a nul-terminated UTF-8 string. For |
| 427 | ** sqlite3_complete16(), a nul-terminated machine byte order UTF-16 string |
| 428 | ** is required. |
| 429 | ** |
| 430 | ** These routines are useful for command-line input to determine if the |
| 431 | ** currently entered text forms one or more complete SQL statements or |
| 432 | ** if additional input is needed before sending the statements into |
| 433 | ** SQLite for parsing. The algorithm is simple. If the |
| 434 | ** last token other than spaces and comments is a semicolon, then return |
| 435 | ** true. Actually, the algorithm is a little more complicated than that |
| 436 | ** in order to deal with triggers, but the basic idea is the same: the |
| 437 | ** statement is not complete unless it ends in a semicolon. |
| 438 | */ |
| 439 | int sqlite3_complete(const char *sql); |
| 440 | int sqlite3_complete16(const void *sql); |
| 441 | |
| 442 | /* |
| 443 | ** CAPI3REF: Register A Callback To Handle SQLITE_BUSY Errors |
| 444 | ** |
| 445 | ** This routine identifies a callback function that might be invoked |
| 446 | ** whenever an attempt is made to open a database table |
| 447 | ** that another thread or process has locked. |
| 448 | ** If the busy callback is NULL, then [SQLITE_BUSY] |
| 449 | ** (or sometimes [SQLITE_IOERR_BLOCKED]) |
| 450 | ** is returned immediately upon encountering the lock. |
| 451 | ** If the busy callback is not NULL, then the |
| 452 | ** callback will be invoked with two arguments. The |
| 453 | ** first argument to the handler is a copy of the void* pointer which |
| 454 | ** is the third argument to this routine. The second argument to |
| 455 | ** the handler is the number of times that the busy handler has |
| 456 | ** been invoked for this locking event. If the |
| 457 | ** busy callback returns 0, then no additional attempts are made to |
| 458 | ** access the database and [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED] is returned. |
| 459 | ** If the callback returns non-zero, then another attempt is made to open the |
| 460 | ** database for reading and the cycle repeats. |
| 461 | ** |
| 462 | ** The presence of a busy handler does not guarantee that |
| 463 | ** it will be invoked when there is lock contention. |
| 464 | ** If SQLite determines that invoking the busy handler could result in |
| 465 | ** a deadlock, it will return [SQLITE_BUSY] instead. |
| 466 | ** Consider a scenario where one process is holding a read lock that |
| 467 | ** it is trying to promote to a reserved lock and |
| 468 | ** a second process is holding a reserved lock that it is trying |
| 469 | ** to promote to an exclusive lock. The first process cannot proceed |
| 470 | ** because it is blocked by the second and the second process cannot |
| 471 | ** proceed because it is blocked by the first. If both processes |
| 472 | ** invoke the busy handlers, neither will make any progress. Therefore, |
| 473 | ** SQLite returns [SQLITE_BUSY] for the first process, hoping that this |
| 474 | ** will induce the first process to release its read lock and allow |
| 475 | ** the second process to proceed. |
| 476 | ** |
| 477 | ** The default busy callback is NULL. |
| 478 | ** |
| 479 | ** The [SQLITE_BUSY] error is converted to [SQLITE_IOERR_BLOCKED] when |
| 480 | ** SQLite is in the middle of a large transaction where all the |
| 481 | ** changes will not fit into the in-memory cache. SQLite will |
| 482 | ** already hold a RESERVED lock on the database file, but it needs |
| 483 | ** to promote this lock to EXCLUSIVE so that it can spill cache |
| 484 | ** pages into the database file without harm to concurrent |
| 485 | ** readers. If it is unable to promote the lock, then the in-memory |
| 486 | ** cache will be left in an inconsistent state and so the error |
| 487 | ** code is promoted from the relatively benign [SQLITE_BUSY] to |
| 488 | ** the more severe [SQLITE_IOERR_BLOCKED]. This error code promotion |
| 489 | ** forces an automatic rollback of the changes. See the |
| 490 | ** <a href="http://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError"> |
| 491 | ** CorruptionFollowingBusyError</a> wiki page for a discussion of why |
| 492 | ** this is important. |
| 493 | ** |
| 494 | ** Sqlite is re-entrant, so the busy handler may start a new query. |
| 495 | ** (It is not clear why anyone would every want to do this, but it |
| 496 | ** is allowed, in theory.) But the busy handler may not close the |
| 497 | ** database. Closing the database from a busy handler will delete |
| 498 | ** data structures out from under the executing query and will |
| 499 | ** probably result in a segmentation fault or other runtime error. |
| 500 | ** |
| 501 | ** There can only be a single busy handler defined for each database |
| 502 | ** connection. Setting a new busy handler clears any previous one. |
| 503 | ** Note that calling [sqlite3_busy_timeout()] will also set or clear |
| 504 | ** the busy handler. |
| 505 | */ |
| 506 | int sqlite3_busy_handler(sqlite3*, int(*)(void*,int), void*); |
| 507 | |
| 508 | /* |
| 509 | ** CAPI3REF: Set A Busy Timeout |
| 510 | ** |
| 511 | ** This routine sets a busy handler that sleeps for a while when a |
| 512 | ** table is locked. The handler will sleep multiple times until |
| 513 | ** at least "ms" milliseconds of sleeping have been done. After |
| 514 | ** "ms" milliseconds of sleeping, the handler returns 0 which |
| 515 | ** causes [sqlite3_step()] to return [SQLITE_BUSY] or [SQLITE_IOERR_BLOCKED]. |
| 516 | ** |
| 517 | ** Calling this routine with an argument less than or equal to zero |
| 518 | ** turns off all busy handlers. |
| 519 | ** |
| 520 | ** There can only be a single busy handler for a particular database |
| 521 | ** connection. If another busy handler was defined |
| 522 | ** (using [sqlite3_busy_handler()]) prior to calling |
| 523 | ** this routine, that other busy handler is cleared. |
| 524 | */ |
| 525 | int sqlite3_busy_timeout(sqlite3*, int ms); |
| 526 | |
| 527 | /* |
| 528 | ** CAPI3REF: Convenience Routines For Running Queries |
| 529 | ** |
| 530 | ** This next routine is a convenience wrapper around [sqlite3_exec()]. |
| 531 | ** Instead of invoking a user-supplied callback for each row of the |
| 532 | ** result, this routine remembers each row of the result in memory |
| 533 | ** obtained from [sqlite3_malloc()], then returns all of the result after the |
| 534 | ** query has finished. |
| 535 | ** |
| 536 | ** As an example, suppose the query result where this table: |
| 537 | ** |
| 538 | ** <pre> |
| 539 | ** Name | Age |
| 540 | ** ----------------------- |
| 541 | ** Alice | 43 |
| 542 | ** Bob | 28 |
| 543 | ** Cindy | 21 |
| 544 | ** </pre> |
| 545 | ** |
| 546 | ** If the 3rd argument were &azResult then after the function returns |
| 547 | ** azResult will contain the following data: |
| 548 | ** |
| 549 | ** <pre> |
| 550 | ** azResult[0] = "Name"; |
| 551 | ** azResult[1] = "Age"; |
| 552 | ** azResult[2] = "Alice"; |
| 553 | ** azResult[3] = "43"; |
| 554 | ** azResult[4] = "Bob"; |
| 555 | ** azResult[5] = "28"; |
| 556 | ** azResult[6] = "Cindy"; |
| 557 | ** azResult[7] = "21"; |
| 558 | ** </pre> |
| 559 | ** |
| 560 | ** Notice that there is an extra row of data containing the column |
| 561 | ** headers. But the *nrow return value is still 3. *ncolumn is |
| 562 | ** set to 2. In general, the number of values inserted into azResult |
| 563 | ** will be ((*nrow) + 1)*(*ncolumn). |
| 564 | ** |
| 565 | ** After the calling function has finished using the result, it should |
| 566 | ** pass the result data pointer to sqlite3_free_table() in order to |
| 567 | ** release the memory that was malloc-ed. Because of the way the |
| 568 | ** [sqlite3_malloc()] happens, the calling function must not try to call |
| 569 | ** [sqlite3_free()] directly. Only [sqlite3_free_table()] is able to release |
| 570 | ** the memory properly and safely. |
| 571 | ** |
| 572 | ** The return value of this routine is the same as from [sqlite3_exec()]. |
| 573 | */ |
| 574 | int sqlite3_get_table( |
| 575 | sqlite3*, /* An open database */ |
| 576 | const char *sql, /* SQL to be executed */ |
| 577 | char ***resultp, /* Result written to a char *[] that this points to */ |
| 578 | int *nrow, /* Number of result rows written here */ |
| 579 | int *ncolumn, /* Number of result columns written here */ |
| 580 | char **errmsg /* Error msg written here */ |
| 581 | ); |
| 582 | void sqlite3_free_table(char **result); |
| 583 | |
| 584 | /* |
| 585 | ** CAPI3REF: Formatted String Printing Functions |
| 586 | ** |
| 587 | ** These routines are workalikes of the "printf()" family of functions |
| 588 | ** from the standard C library. |
| 589 | ** |
| 590 | ** The sqlite3_mprintf() and sqlite3_vmprintf() routines write their |
| 591 | ** results into memory obtained from [sqlite_malloc()]. |
| 592 | ** The strings returned by these two routines should be |
| 593 | ** released by [sqlite3_free()]. Both routines return a |
| 594 | ** NULL pointer if [sqlite3_malloc()] is unable to allocate enough |
| 595 | ** memory to hold the resulting string. |
| 596 | ** |
| 597 | ** In sqlite3_snprintf() routine is similar to "snprintf()" from |
| 598 | ** the standard C library. The result is written into the |
| 599 | ** buffer supplied as the second parameter whose size is given by |
| 600 | ** the first parameter. Note that the order of the |
| 601 | ** first two parameters is reversed from snprintf(). This is an |
| 602 | ** historical accident that cannot be fixed without breaking |
| 603 | ** backwards compatibility. Note also that sqlite3_snprintf() |
| 604 | ** returns a pointer to its buffer instead of the number of |
| 605 | ** characters actually written into the buffer. We admit that |
| 606 | ** the number of characters written would be a more useful return |
| 607 | ** value but we cannot change the implementation of sqlite3_snprintf() |
| 608 | ** now without breaking compatibility. |
| 609 | ** |
| 610 | ** As long as the buffer size is greater than zero, sqlite3_snprintf() |
| 611 | ** guarantees that the buffer is always zero-terminated. The first |
| 612 | ** parameter "n" is the total size of the buffer, including space for |
| 613 | ** the zero terminator. So the longest string that can be completely |
| 614 | ** written will be n-1 characters. |
| 615 | ** |
| 616 | ** These routines all implement some additional formatting |
| 617 | ** options that are useful for constructing SQL statements. |
| 618 | ** All of the usual printf formatting options apply. In addition, there |
| 619 | ** is are "%q" and "%Q" options. |
| 620 | ** |
| 621 | ** The %q option works like %s in that it substitutes a null-terminated |
| 622 | ** string from the argument list. But %q also doubles every '\'' character. |
| 623 | ** %q is designed for use inside a string literal. By doubling each '\'' |
| 624 | ** character it escapes that character and allows it to be inserted into |
| 625 | ** the string. |
| 626 | ** |
| 627 | ** For example, so some string variable contains text as follows: |
| 628 | ** |
| 629 | ** <blockquote><pre> |
| 630 | ** char *zText = "It's a happy day!"; |
| 631 | ** </pre></blockquote> |
| 632 | ** |
| 633 | ** One can use this text in an SQL statement as follows: |
| 634 | ** |
| 635 | ** <blockquote><pre> |
| 636 | ** char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES('%q')", zText); |
| 637 | ** sqlite3_exec(db, zSQL, 0, 0, 0); |
| 638 | ** sqlite3_free(zSQL); |
| 639 | ** </pre></blockquote> |
| 640 | ** |
| 641 | ** Because the %q format string is used, the '\'' character in zText |
| 642 | ** is escaped and the SQL generated is as follows: |
| 643 | ** |
| 644 | ** <blockquote><pre> |
| 645 | ** INSERT INTO table1 VALUES('It''s a happy day!') |
| 646 | ** </pre></blockquote> |
| 647 | ** |
| 648 | ** This is correct. Had we used %s instead of %q, the generated SQL |
| 649 | ** would have looked like this: |
| 650 | ** |
| 651 | ** <blockquote><pre> |
| 652 | ** INSERT INTO table1 VALUES('It's a happy day!'); |
| 653 | ** </pre></blockquote> |
| 654 | ** |
| 655 | ** This second example is an SQL syntax error. As a general rule you |
| 656 | ** should always use %q instead of %s when inserting text into a string |
| 657 | ** literal. |
| 658 | ** |
| 659 | ** The %Q option works like %q except it also adds single quotes around |
| 660 | ** the outside of the total string. Or if the parameter in the argument |
| 661 | ** list is a NULL pointer, %Q substitutes the text "NULL" (without single |
| 662 | ** quotes) in place of the %Q option. So, for example, one could say: |
| 663 | ** |
| 664 | ** <blockquote><pre> |
| 665 | ** char *zSQL = sqlite3_mprintf("INSERT INTO table VALUES(%Q)", zText); |
| 666 | ** sqlite3_exec(db, zSQL, 0, 0, 0); |
| 667 | ** sqlite3_free(zSQL); |
| 668 | ** </pre></blockquote> |
| 669 | ** |
| 670 | ** The code above will render a correct SQL statement in the zSQL |
| 671 | ** variable even if the zText variable is a NULL pointer. |
| 672 | */ |
| 673 | char *sqlite3_mprintf(const char*,...); |
| 674 | char *sqlite3_vmprintf(const char*, va_list); |
| 675 | char *sqlite3_snprintf(int,char*,const char*, ...); |
| 676 | |
| 677 | /* |
| 678 | ** CAPI3REF: Memory Allocation Functions |
| 679 | ** |
| 680 | ** SQLite uses its own memory allocator. On some installations, this |
| 681 | ** memory allocator is identical to the standard malloc()/realloc()/free() |
| 682 | ** and can be used interchangable. On others, the implementations are |
| 683 | ** different. For maximum portability, it is best not to mix calls |
| 684 | ** to the standard malloc/realloc/free with the sqlite versions. |
| 685 | */ |
| 686 | void *sqlite3_malloc(int); |
| 687 | void *sqlite3_realloc(void*, int); |
| 688 | void sqlite3_free(void*); |
| 689 | |
| 690 | /* |
| 691 | ** CAPI3REF: Compile-Time Authorization Callbacks |
| 692 | *** |
| 693 | ** This routine registers a authorizer callback with the SQLite library. |
| 694 | ** The authorizer callback is invoked as SQL statements are being compiled |
| 695 | ** by [sqlite3_prepare()] or its variants [sqlite3_prepare_v2()], |
| 696 | ** [sqlite3_prepare16()] and [sqlite3_prepare16_v2()]. At various |
| 697 | ** points during the compilation process, as logic is being created |
| 698 | ** to perform various actions, the authorizer callback is invoked to |
| 699 | ** see if those actions are allowed. The authorizer callback should |
| 700 | ** return SQLITE_OK to allow the action, [SQLITE_IGNORE] to disallow the |
| 701 | ** specific action but allow the SQL statement to continue to be |
| 702 | ** compiled, or [SQLITE_DENY] to cause the entire SQL statement to be |
| 703 | ** rejected with an error. |
| 704 | ** |
| 705 | ** Depending on the action, the [SQLITE_IGNORE] and [SQLITE_DENY] return |
| 706 | ** codes might mean something different or they might mean the same |
| 707 | ** thing. If the action is, for example, to perform a delete opertion, |
| 708 | ** then [SQLITE_IGNORE] and [SQLITE_DENY] both cause the statement compilation |
| 709 | ** to fail with an error. But if the action is to read a specific column |
| 710 | ** from a specific table, then [SQLITE_DENY] will cause the entire |
| 711 | ** statement to fail but [SQLITE_IGNORE] will cause a NULL value to be |
| 712 | ** read instead of the actual column value. |
| 713 | ** |
| 714 | ** The first parameter to the authorizer callback is a copy of |
| 715 | ** the third parameter to the sqlite3_set_authorizer() interface. |
| 716 | ** The second parameter to the callback is an integer |
| 717 | ** [SQLITE_COPY | action code] that specifies the particular action |
| 718 | ** to be authorized. The available action codes are |
| 719 | ** [SQLITE_COPY | documented separately]. The third through sixth |
| 720 | ** parameters to the callback are strings that contain additional |
| 721 | ** details about the action to be authorized. |
| 722 | ** |
| 723 | ** An authorizer is used when preparing SQL statements from an untrusted |
| 724 | ** source, to ensure that the SQL statements do not try to access data |
| 725 | ** that they are not allowed to see, or that they do not try to |
| 726 | ** execute malicious statements that damage the database. For |
| 727 | ** example, an application may allow a user to enter arbitrary |
| 728 | ** SQL queries for evaluation by a database. But the application does |
| 729 | ** not want the user to be able to make arbitrary changes to the |
| 730 | ** database. An authorizer could then be put in place while the |
| 731 | ** user-entered SQL is being prepared that disallows everything |
| 732 | ** except SELECT statements. |
| 733 | ** |
| 734 | ** Only a single authorizer can be in place on a database connection |
| 735 | ** at a time. Each call to sqlite3_set_authorizer overrides the |
| 736 | ** previous call. A NULL authorizer means that no authorization |
| 737 | ** callback is invoked. The default authorizer is NULL. |
| 738 | ** |
| 739 | ** Note that the authorizer callback is invoked only during |
| 740 | ** [sqlite3_prepare()] or its variants. Authorization is not |
| 741 | ** performed during statement evaluation in [sqlite3_step()]. |
| 742 | */ |
| 743 | int sqlite3_set_authorizer( |
| 744 | sqlite3*, |
| 745 | int (*xAuth)(void*,int,const char*,const char*,const char*,const char*), |
| 746 | void *pUserData |
| 747 | ); |
| 748 | |
| 749 | /* |
| 750 | ** CAPI3REF: Authorizer Return Codes |
| 751 | ** |
| 752 | ** The [sqlite3_set_authorizer | authorizer callback function] must |
| 753 | ** return either [SQLITE_OK] or one of these two constants in order |
| 754 | ** to signal SQLite whether or not the action is permitted. See the |
| 755 | ** [sqlite3_set_authorizer | authorizer documentation] for additional |
| 756 | ** information. |
| 757 | */ |
| 758 | #define SQLITE_DENY 1 /* Abort the SQL statement with an error */ |
| 759 | #define SQLITE_IGNORE 2 /* Don't allow access, but don't generate an error */ |
| 760 | |
| 761 | /* |
| 762 | ** CAPI3REF: Authorizer Action Codes |
| 763 | ** |
| 764 | ** The [sqlite3_set_authorizer()] interface registers a callback function |
| 765 | ** that is invoked to authorizer certain SQL statement actions. The |
| 766 | ** second parameter to the callback is an integer code that specifies |
| 767 | ** what action is being authorized. These are the integer action codes that |
| 768 | ** the authorizer callback may be passed. |
| 769 | ** |
| 770 | ** These action code values signify what kind of operation is to be |
| 771 | ** authorized. The 3rd and 4th parameters to the authorization callback |
| 772 | ** function will be parameters or NULL depending on which of these |
| 773 | ** codes is used as the second parameter. The 5th parameter to the |
| 774 | ** authorizer callback is the name of the database ("main", "temp", |
| 775 | ** etc.) if applicable. The 6th parameter to the authorizer callback |
| 776 | ** is the name of the inner-most trigger or view that is responsible for |
| 777 | ** the access attempt or NULL if this access attempt is directly from |
| 778 | ** top-level SQL code. |
| 779 | */ |
| 780 | /******************************************* 3rd ************ 4th ***********/ |
| 781 | #define SQLITE_CREATE_INDEX 1 /* Index Name Table Name */ |
| 782 | #define SQLITE_CREATE_TABLE 2 /* Table Name NULL */ |
| 783 | #define SQLITE_CREATE_TEMP_INDEX 3 /* Index Name Table Name */ |
| 784 | #define SQLITE_CREATE_TEMP_TABLE 4 /* Table Name NULL */ |
| 785 | #define SQLITE_CREATE_TEMP_TRIGGER 5 /* Trigger Name Table Name */ |
| 786 | #define SQLITE_CREATE_TEMP_VIEW 6 /* View Name NULL */ |
| 787 | #define SQLITE_CREATE_TRIGGER 7 /* Trigger Name Table Name */ |
| 788 | #define SQLITE_CREATE_VIEW 8 /* View Name NULL */ |
| 789 | #define SQLITE_DELETE 9 /* Table Name NULL */ |
| 790 | #define SQLITE_DROP_INDEX 10 /* Index Name Table Name */ |
| 791 | #define SQLITE_DROP_TABLE 11 /* Table Name NULL */ |
| 792 | # |
