/src/sqlite3/bld/sqlite3.h
Line  | Count  | Source  | 
1  |  | /*  | 
2  |  | ** 2001-09-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 the right to make minor changes  | 
22  |  | ** if 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 supposed 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  |  | #ifndef SQLITE3_H  | 
34  |  | #define SQLITE3_H  | 
35  |  | #include <stdarg.h>     /* Needed for the definition of va_list */  | 
36  |  |  | 
37  |  | /*  | 
38  |  | ** Make sure we can call this stuff from C++.  | 
39  |  | */  | 
40  |  | #ifdef __cplusplus  | 
41  |  | extern "C" { | 
42  |  | #endif  | 
43  |  |  | 
44  |  |  | 
45  |  | /*  | 
46  |  | ** Provide the ability to override linkage features of the interface.  | 
47  |  | */  | 
48  |  | #ifndef SQLITE_EXTERN  | 
49  |  | # define SQLITE_EXTERN extern  | 
50  |  | #endif  | 
51  |  | #ifndef SQLITE_API  | 
52  |  | # define SQLITE_API  | 
53  |  | #endif  | 
54  |  | #ifndef SQLITE_CDECL  | 
55  |  | # define SQLITE_CDECL  | 
56  |  | #endif  | 
57  |  | #ifndef SQLITE_APICALL  | 
58  |  | # define SQLITE_APICALL  | 
59  |  | #endif  | 
60  |  | #ifndef SQLITE_STDCALL  | 
61  |  | # define SQLITE_STDCALL SQLITE_APICALL  | 
62  |  | #endif  | 
63  |  | #ifndef SQLITE_CALLBACK  | 
64  |  | # define SQLITE_CALLBACK  | 
65  |  | #endif  | 
66  |  | #ifndef SQLITE_SYSAPI  | 
67  |  | # define SQLITE_SYSAPI  | 
68  |  | #endif  | 
69  |  |  | 
70  |  | /*  | 
71  |  | ** These no-op macros are used in front of interfaces to mark those  | 
72  |  | ** interfaces as either deprecated or experimental.  New applications  | 
73  |  | ** should not use deprecated interfaces - they are supported for backwards  | 
74  |  | ** compatibility only.  Application writers should be aware that  | 
75  |  | ** experimental interfaces are subject to change in point releases.  | 
76  |  | **  | 
77  |  | ** These macros used to resolve to various kinds of compiler magic that  | 
78  |  | ** would generate warning messages when they were used.  But that  | 
79  |  | ** compiler magic ended up generating such a flurry of bug reports  | 
80  |  | ** that we have taken it all out and gone back to using simple  | 
81  |  | ** noop macros.  | 
82  |  | */  | 
83  |  | #define SQLITE_DEPRECATED  | 
84  |  | #define SQLITE_EXPERIMENTAL  | 
85  |  |  | 
86  |  | /*  | 
87  |  | ** Ensure these symbols were not defined by some previous header file.  | 
88  |  | */  | 
89  |  | #ifdef SQLITE_VERSION  | 
90  |  | # undef SQLITE_VERSION  | 
91  |  | #endif  | 
92  |  | #ifdef SQLITE_VERSION_NUMBER  | 
93  |  | # undef SQLITE_VERSION_NUMBER  | 
94  |  | #endif  | 
95  |  |  | 
96  |  | /*  | 
97  |  | ** CAPI3REF: Compile-Time Library Version Numbers  | 
98  |  | **  | 
99  |  | ** ^(The [SQLITE_VERSION] C preprocessor macro in the sqlite3.h header  | 
100  |  | ** evaluates to a string literal that is the SQLite version in the  | 
101  |  | ** format "X.Y.Z" where X is the major version number (always 3 for  | 
102  |  | ** SQLite3) and Y is the minor version number and Z is the release number.)^  | 
103  |  | ** ^(The [SQLITE_VERSION_NUMBER] C preprocessor macro resolves to an integer  | 
104  |  | ** with the value (X*1000000 + Y*1000 + Z) where X, Y, and Z are the same  | 
105  |  | ** numbers used in [SQLITE_VERSION].)^  | 
106  |  | ** The SQLITE_VERSION_NUMBER for any given release of SQLite will also  | 
107  |  | ** be larger than the release from which it is derived.  Either Y will  | 
108  |  | ** be held constant and Z will be incremented or else Y will be incremented  | 
109  |  | ** and Z will be reset to zero.  | 
110  |  | **  | 
111  |  | ** Since [version 3.6.18] ([dateof:3.6.18]),  | 
112  |  | ** SQLite source code has been stored in the  | 
113  |  | ** <a href="http://www.fossil-scm.org/">Fossil configuration management  | 
114  |  | ** system</a>.  ^The SQLITE_SOURCE_ID macro evaluates to  | 
115  |  | ** a string which identifies a particular check-in of SQLite  | 
116  |  | ** within its configuration management system.  ^The SQLITE_SOURCE_ID  | 
117  |  | ** string contains the date and time of the check-in (UTC) and a SHA1  | 
118  |  | ** or SHA3-256 hash of the entire source tree.  If the source code has  | 
119  |  | ** been edited in any way since it was last checked in, then the last  | 
120  |  | ** four hexadecimal digits of the hash may be modified.  | 
121  |  | **  | 
122  |  | ** See also: [sqlite3_libversion()],  | 
123  |  | ** [sqlite3_libversion_number()], [sqlite3_sourceid()],  | 
124  |  | ** [sqlite_version()] and [sqlite_source_id()].  | 
125  |  | */  | 
126  |  | #define SQLITE_VERSION        "3.33.0"  | 
127  |  | #define SQLITE_VERSION_NUMBER 3033000  | 
128  |  | #define SQLITE_SOURCE_ID      "2020-06-26 15:32:29 c78cbf2e86850cc6882d3f0bd5415f6e731c3c675ffe77bb343682c619cb8cd9"  | 
129  |  |  | 
130  |  | /*  | 
131  |  | ** CAPI3REF: Run-Time Library Version Numbers  | 
132  |  | ** KEYWORDS: sqlite3_version sqlite3_sourceid  | 
133  |  | **  | 
134  |  | ** These interfaces provide the same information as the [SQLITE_VERSION],  | 
135  |  | ** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] C preprocessor macros  | 
136  |  | ** but are associated with the library instead of the header file.  ^(Cautious  | 
137  |  | ** programmers might include assert() statements in their application to  | 
138  |  | ** verify that values returned by these interfaces match the macros in  | 
139  |  | ** the header, and thus ensure that the application is  | 
140  |  | ** compiled with matching library and header files.  | 
141  |  | **  | 
142  |  | ** <blockquote><pre>  | 
143  |  | ** assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );  | 
144  |  | ** assert( strncmp(sqlite3_sourceid(),SQLITE_SOURCE_ID,80)==0 );  | 
145  |  | ** assert( strcmp(sqlite3_libversion(),SQLITE_VERSION)==0 );  | 
146  |  | ** </pre></blockquote>)^  | 
147  |  | **  | 
148  |  | ** ^The sqlite3_version[] string constant contains the text of [SQLITE_VERSION]  | 
149  |  | ** macro.  ^The sqlite3_libversion() function returns a pointer to the  | 
150  |  | ** to the sqlite3_version[] string constant.  The sqlite3_libversion()  | 
151  |  | ** function is provided for use in DLLs since DLL users usually do not have  | 
152  |  | ** direct access to string constants within the DLL.  ^The  | 
153  |  | ** sqlite3_libversion_number() function returns an integer equal to  | 
154  |  | ** [SQLITE_VERSION_NUMBER].  ^(The sqlite3_sourceid() function returns  | 
155  |  | ** a pointer to a string constant whose value is the same as the  | 
156  |  | ** [SQLITE_SOURCE_ID] C preprocessor macro.  Except if SQLite is built  | 
157  |  | ** using an edited copy of [the amalgamation], then the last four characters  | 
158  |  | ** of the hash might be different from [SQLITE_SOURCE_ID].)^  | 
159  |  | **  | 
160  |  | ** See also: [sqlite_version()] and [sqlite_source_id()].  | 
161  |  | */  | 
162  |  | SQLITE_API SQLITE_EXTERN const char sqlite3_version[];  | 
163  |  | SQLITE_API const char *sqlite3_libversion(void);  | 
164  |  | SQLITE_API const char *sqlite3_sourceid(void);  | 
165  |  | SQLITE_API int sqlite3_libversion_number(void);  | 
166  |  |  | 
167  |  | /*  | 
168  |  | ** CAPI3REF: Run-Time Library Compilation Options Diagnostics  | 
169  |  | **  | 
170  |  | ** ^The sqlite3_compileoption_used() function returns 0 or 1  | 
171  |  | ** indicating whether the specified option was defined at  | 
172  |  | ** compile time.  ^The SQLITE_ prefix may be omitted from the  | 
173  |  | ** option name passed to sqlite3_compileoption_used().  | 
174  |  | **  | 
175  |  | ** ^The sqlite3_compileoption_get() function allows iterating  | 
176  |  | ** over the list of options that were defined at compile time by  | 
177  |  | ** returning the N-th compile time option string.  ^If N is out of range,  | 
178  |  | ** sqlite3_compileoption_get() returns a NULL pointer.  ^The SQLITE_  | 
179  |  | ** prefix is omitted from any strings returned by  | 
180  |  | ** sqlite3_compileoption_get().  | 
181  |  | **  | 
182  |  | ** ^Support for the diagnostic functions sqlite3_compileoption_used()  | 
183  |  | ** and sqlite3_compileoption_get() may be omitted by specifying the  | 
184  |  | ** [SQLITE_OMIT_COMPILEOPTION_DIAGS] option at compile time.  | 
185  |  | **  | 
186  |  | ** See also: SQL functions [sqlite_compileoption_used()] and  | 
187  |  | ** [sqlite_compileoption_get()] and the [compile_options pragma].  | 
188  |  | */  | 
189  |  | #ifndef SQLITE_OMIT_COMPILEOPTION_DIAGS  | 
190  |  | SQLITE_API int sqlite3_compileoption_used(const char *zOptName);  | 
191  |  | SQLITE_API const char *sqlite3_compileoption_get(int N);  | 
192  |  | #else  | 
193  |  | # define sqlite3_compileoption_used(X) 0  | 
194  |  | # define sqlite3_compileoption_get(X)  ((void*)0)  | 
195  |  | #endif  | 
196  |  |  | 
197  |  | /*  | 
198  |  | ** CAPI3REF: Test To See If The Library Is Threadsafe  | 
199  |  | **  | 
200  |  | ** ^The sqlite3_threadsafe() function returns zero if and only if  | 
201  |  | ** SQLite was compiled with mutexing code omitted due to the  | 
202  |  | ** [SQLITE_THREADSAFE] compile-time option being set to 0.  | 
203  |  | **  | 
204  |  | ** SQLite can be compiled with or without mutexes.  When  | 
205  |  | ** the [SQLITE_THREADSAFE] C preprocessor macro is 1 or 2, mutexes  | 
206  |  | ** are enabled and SQLite is threadsafe.  When the  | 
207  |  | ** [SQLITE_THREADSAFE] macro is 0,  | 
208  |  | ** the mutexes are omitted.  Without the mutexes, it is not safe  | 
209  |  | ** to use SQLite concurrently from more than one thread.  | 
210  |  | **  | 
211  |  | ** Enabling mutexes incurs a measurable performance penalty.  | 
212  |  | ** So if speed is of utmost importance, it makes sense to disable  | 
213  |  | ** the mutexes.  But for maximum safety, mutexes should be enabled.  | 
214  |  | ** ^The default behavior is for mutexes to be enabled.  | 
215  |  | **  | 
216  |  | ** This interface can be used by an application to make sure that the  | 
217  |  | ** version of SQLite that it is linking against was compiled with  | 
218  |  | ** the desired setting of the [SQLITE_THREADSAFE] macro.  | 
219  |  | **  | 
220  |  | ** This interface only reports on the compile-time mutex setting  | 
221  |  | ** of the [SQLITE_THREADSAFE] flag.  If SQLite is compiled with  | 
222  |  | ** SQLITE_THREADSAFE=1 or =2 then mutexes are enabled by default but  | 
223  |  | ** can be fully or partially disabled using a call to [sqlite3_config()]  | 
224  |  | ** with the verbs [SQLITE_CONFIG_SINGLETHREAD], [SQLITE_CONFIG_MULTITHREAD],  | 
225  |  | ** or [SQLITE_CONFIG_SERIALIZED].  ^(The return value of the  | 
226  |  | ** sqlite3_threadsafe() function shows only the compile-time setting of  | 
227  |  | ** thread safety, not any run-time changes to that setting made by  | 
228  |  | ** sqlite3_config(). In other words, the return value from sqlite3_threadsafe()  | 
229  |  | ** is unchanged by calls to sqlite3_config().)^  | 
230  |  | **  | 
231  |  | ** See the [threading mode] documentation for additional information.  | 
232  |  | */  | 
233  |  | SQLITE_API int sqlite3_threadsafe(void);  | 
234  |  |  | 
235  |  | /*  | 
236  |  | ** CAPI3REF: Database Connection Handle  | 
237  |  | ** KEYWORDS: {database connection} {database connections} | 
238  |  | **  | 
239  |  | ** Each open SQLite database is represented by a pointer to an instance of  | 
240  |  | ** the opaque structure named "sqlite3".  It is useful to think of an sqlite3  | 
241  |  | ** pointer as an object.  The [sqlite3_open()], [sqlite3_open16()], and  | 
242  |  | ** [sqlite3_open_v2()] interfaces are its constructors, and [sqlite3_close()]  | 
243  |  | ** and [sqlite3_close_v2()] are its destructors.  There are many other  | 
244  |  | ** interfaces (such as  | 
245  |  | ** [sqlite3_prepare_v2()], [sqlite3_create_function()], and  | 
246  |  | ** [sqlite3_busy_timeout()] to name but three) that are methods on an  | 
247  |  | ** sqlite3 object.  | 
248  |  | */  | 
249  |  | typedef struct sqlite3 sqlite3;  | 
250  |  |  | 
251  |  | /*  | 
252  |  | ** CAPI3REF: 64-Bit Integer Types  | 
253  |  | ** KEYWORDS: sqlite_int64 sqlite_uint64  | 
254  |  | **  | 
255  |  | ** Because there is no cross-platform way to specify 64-bit integer types  | 
256  |  | ** SQLite includes typedefs for 64-bit signed and unsigned integers.  | 
257  |  | **  | 
258  |  | ** The sqlite3_int64 and sqlite3_uint64 are the preferred type definitions.  | 
259  |  | ** The sqlite_int64 and sqlite_uint64 types are supported for backwards  | 
260  |  | ** compatibility only.  | 
261  |  | **  | 
262  |  | ** ^The sqlite3_int64 and sqlite_int64 types can store integer values  | 
263  |  | ** between -9223372036854775808 and +9223372036854775807 inclusive.  ^The  | 
264  |  | ** sqlite3_uint64 and sqlite_uint64 types can store integer values  | 
265  |  | ** between 0 and +18446744073709551615 inclusive.  | 
266  |  | */  | 
267  |  | #ifdef SQLITE_INT64_TYPE  | 
268  |  |   typedef SQLITE_INT64_TYPE sqlite_int64;  | 
269  |  | # ifdef SQLITE_UINT64_TYPE  | 
270  |  |     typedef SQLITE_UINT64_TYPE sqlite_uint64;  | 
271  |  | # else  | 
272  |  |     typedef unsigned SQLITE_INT64_TYPE sqlite_uint64;  | 
273  |  | # endif  | 
274  |  | #elif defined(_MSC_VER) || defined(__BORLANDC__)  | 
275  |  |   typedef __int64 sqlite_int64;  | 
276  |  |   typedef unsigned __int64 sqlite_uint64;  | 
277  |  | #else  | 
278  |  |   typedef long long int sqlite_int64;  | 
279  |  |   typedef unsigned long long int sqlite_uint64;  | 
280  |  | #endif  | 
281  |  | typedef sqlite_int64 sqlite3_int64;  | 
282  |  | typedef sqlite_uint64 sqlite3_uint64;  | 
283  |  |  | 
284  |  | /*  | 
285  |  | ** If compiling for a processor that lacks floating point support,  | 
286  |  | ** substitute integer for floating-point.  | 
287  |  | */  | 
288  |  | #ifdef SQLITE_OMIT_FLOATING_POINT  | 
289  |  | # define double sqlite3_int64  | 
290  |  | #endif  | 
291  |  |  | 
292  |  | /*  | 
293  |  | ** CAPI3REF: Closing A Database Connection  | 
294  |  | ** DESTRUCTOR: sqlite3  | 
295  |  | **  | 
296  |  | ** ^The sqlite3_close() and sqlite3_close_v2() routines are destructors  | 
297  |  | ** for the [sqlite3] object.  | 
298  |  | ** ^Calls to sqlite3_close() and sqlite3_close_v2() return [SQLITE_OK] if  | 
299  |  | ** the [sqlite3] object is successfully destroyed and all associated  | 
300  |  | ** resources are deallocated.  | 
301  |  | **  | 
302  |  | ** Ideally, applications should [sqlite3_finalize | finalize] all  | 
303  |  | ** [prepared statements], [sqlite3_blob_close | close] all [BLOB handles], and  | 
304  |  | ** [sqlite3_backup_finish | finish] all [sqlite3_backup] objects associated  | 
305  |  | ** with the [sqlite3] object prior to attempting to close the object.  | 
306  |  | ** ^If the database connection is associated with unfinalized prepared  | 
307  |  | ** statements, BLOB handlers, and/or unfinished sqlite3_backup objects then  | 
308  |  | ** sqlite3_close() will leave the database connection open and return  | 
309  |  | ** [SQLITE_BUSY]. ^If sqlite3_close_v2() is called with unfinalized prepared  | 
310  |  | ** statements, unclosed BLOB handlers, and/or unfinished sqlite3_backups,  | 
311  |  | ** it returns [SQLITE_OK] regardless, but instead of deallocating the database  | 
312  |  | ** connection immediately, it marks the database connection as an unusable  | 
313  |  | ** "zombie" and makes arrangements to automatically deallocate the database  | 
314  |  | ** connection after all prepared statements are finalized, all BLOB handles  | 
315  |  | ** are closed, and all backups have finished. The sqlite3_close_v2() interface  | 
316  |  | ** is intended for use with host languages that are garbage collected, and  | 
317  |  | ** where the order in which destructors are called is arbitrary.  | 
318  |  | **  | 
319  |  | ** ^If an [sqlite3] object is destroyed while a transaction is open,  | 
320  |  | ** the transaction is automatically rolled back.  | 
321  |  | **  | 
322  |  | ** The C parameter to [sqlite3_close(C)] and [sqlite3_close_v2(C)]  | 
323  |  | ** must be either a NULL  | 
324  |  | ** pointer or an [sqlite3] object pointer obtained  | 
325  |  | ** from [sqlite3_open()], [sqlite3_open16()], or  | 
326  |  | ** [sqlite3_open_v2()], and not previously closed.  | 
327  |  | ** ^Calling sqlite3_close() or sqlite3_close_v2() with a NULL pointer  | 
328  |  | ** argument is a harmless no-op.  | 
329  |  | */  | 
330  |  | SQLITE_API int sqlite3_close(sqlite3*);  | 
331  |  | SQLITE_API int sqlite3_close_v2(sqlite3*);  | 
332  |  |  | 
333  |  | /*  | 
334  |  | ** The type for a callback function.  | 
335  |  | ** This is legacy and deprecated.  It is included for historical  | 
336  |  | ** compatibility and is not documented.  | 
337  |  | */  | 
338  |  | typedef int (*sqlite3_callback)(void*,int,char**, char**);  | 
339  |  |  | 
340  |  | /*  | 
341  |  | ** CAPI3REF: One-Step Query Execution Interface  | 
342  |  | ** METHOD: sqlite3  | 
343  |  | **  | 
344  |  | ** The sqlite3_exec() interface is a convenience wrapper around  | 
345  |  | ** [sqlite3_prepare_v2()], [sqlite3_step()], and [sqlite3_finalize()],  | 
346  |  | ** that allows an application to run multiple statements of SQL  | 
347  |  | ** without having to use a lot of C code.  | 
348  |  | **  | 
349  |  | ** ^The sqlite3_exec() interface runs zero or more UTF-8 encoded,  | 
350  |  | ** semicolon-separate SQL statements passed into its 2nd argument,  | 
351  |  | ** in the context of the [database connection] passed in as its 1st  | 
352  |  | ** argument.  ^If the callback function of the 3rd argument to  | 
353  |  | ** sqlite3_exec() is not NULL, then it is invoked for each result row  | 
354  |  | ** coming out of the evaluated SQL statements.  ^The 4th argument to  | 
355  |  | ** sqlite3_exec() is relayed through to the 1st argument of each  | 
356  |  | ** callback invocation.  ^If the callback pointer to sqlite3_exec()  | 
357  |  | ** is NULL, then no callback is ever invoked and result rows are  | 
358  |  | ** ignored.  | 
359  |  | **  | 
360  |  | ** ^If an error occurs while evaluating the SQL statements passed into  | 
361  |  | ** sqlite3_exec(), then execution of the current statement stops and  | 
362  |  | ** subsequent statements are skipped.  ^If the 5th parameter to sqlite3_exec()  | 
363  |  | ** is not NULL then any error message is written into memory obtained  | 
364  |  | ** from [sqlite3_malloc()] and passed back through the 5th parameter.  | 
365  |  | ** To avoid memory leaks, the application should invoke [sqlite3_free()]  | 
366  |  | ** on error message strings returned through the 5th parameter of  | 
367  |  | ** sqlite3_exec() after the error message string is no longer needed.  | 
368  |  | ** ^If the 5th parameter to sqlite3_exec() is not NULL and no errors  | 
369  |  | ** occur, then sqlite3_exec() sets the pointer in its 5th parameter to  | 
370  |  | ** NULL before returning.  | 
371  |  | **  | 
372  |  | ** ^If an sqlite3_exec() callback returns non-zero, the sqlite3_exec()  | 
373  |  | ** routine returns SQLITE_ABORT without invoking the callback again and  | 
374  |  | ** without running any subsequent SQL statements.  | 
375  |  | **  | 
376  |  | ** ^The 2nd argument to the sqlite3_exec() callback function is the  | 
377  |  | ** number of columns in the result.  ^The 3rd argument to the sqlite3_exec()  | 
378  |  | ** callback is an array of pointers to strings obtained as if from  | 
379  |  | ** [sqlite3_column_text()], one for each column.  ^If an element of a  | 
380  |  | ** result row is NULL then the corresponding string pointer for the  | 
381  |  | ** sqlite3_exec() callback is a NULL pointer.  ^The 4th argument to the  | 
382  |  | ** sqlite3_exec() callback is an array of pointers to strings where each  | 
383  |  | ** entry represents the name of corresponding result column as obtained  | 
384  |  | ** from [sqlite3_column_name()].  | 
385  |  | **  | 
386  |  | ** ^If the 2nd parameter to sqlite3_exec() is a NULL pointer, a pointer  | 
387  |  | ** to an empty string, or a pointer that contains only whitespace and/or  | 
388  |  | ** SQL comments, then no SQL statements are evaluated and the database  | 
389  |  | ** is not changed.  | 
390  |  | **  | 
391  |  | ** Restrictions:  | 
392  |  | **  | 
393  |  | ** <ul>  | 
394  |  | ** <li> The application must ensure that the 1st parameter to sqlite3_exec()  | 
395  |  | **      is a valid and open [database connection].  | 
396  |  | ** <li> The application must not close the [database connection] specified by  | 
397  |  | **      the 1st parameter to sqlite3_exec() while sqlite3_exec() is running.  | 
398  |  | ** <li> The application must not modify the SQL statement text passed into  | 
399  |  | **      the 2nd parameter of sqlite3_exec() while sqlite3_exec() is running.  | 
400  |  | ** </ul>  | 
401  |  | */  | 
402  |  | SQLITE_API int sqlite3_exec(  | 
403  |  |   sqlite3*,                                  /* An open database */  | 
404  |  |   const char *sql,                           /* SQL to be evaluated */  | 
405  |  |   int (*callback)(void*,int,char**,char**),  /* Callback function */  | 
406  |  |   void *,                                    /* 1st argument to callback */  | 
407  |  |   char **errmsg                              /* Error msg written here */  | 
408  |  | );  | 
409  |  |  | 
410  |  | /*  | 
411  |  | ** CAPI3REF: Result Codes  | 
412  |  | ** KEYWORDS: {result code definitions} | 
413  |  | **  | 
414  |  | ** Many SQLite functions return an integer result code from the set shown  | 
415  |  | ** here in order to indicate success or failure.  | 
416  |  | **  | 
417  |  | ** New error codes may be added in future versions of SQLite.  | 
418  |  | **  | 
419  |  | ** See also: [extended result code definitions]  | 
420  |  | */  | 
421  | 135k  | #define SQLITE_OK           0   /* Successful result */  | 
422  |  | /* beginning-of-error-codes */  | 
423  |  | #define SQLITE_ERROR        1   /* Generic error */  | 
424  |  | #define SQLITE_INTERNAL     2   /* Internal logic error in SQLite */  | 
425  |  | #define SQLITE_PERM         3   /* Access permission denied */  | 
426  |  | #define SQLITE_ABORT        4   /* Callback routine requested an abort */  | 
427  |  | #define SQLITE_BUSY         5   /* The database file is locked */  | 
428  |  | #define SQLITE_LOCKED       6   /* A table in the database is locked */  | 
429  |  | #define SQLITE_NOMEM        7   /* A malloc() failed */  | 
430  |  | #define SQLITE_READONLY     8   /* Attempt to write a readonly database */  | 
431  |  | #define SQLITE_INTERRUPT    9   /* Operation terminated by sqlite3_interrupt()*/  | 
432  |  | #define SQLITE_IOERR       10   /* Some kind of disk I/O error occurred */  | 
433  |  | #define SQLITE_CORRUPT     11   /* The database disk image is malformed */  | 
434  |  | #define SQLITE_NOTFOUND    12   /* Unknown opcode in sqlite3_file_control() */  | 
435  |  | #define SQLITE_FULL        13   /* Insertion failed because database is full */  | 
436  |  | #define SQLITE_CANTOPEN    14   /* Unable to open the database file */  | 
437  |  | #define SQLITE_PROTOCOL    15   /* Database lock protocol error */  | 
438  |  | #define SQLITE_EMPTY       16   /* Internal use only */  | 
439  |  | #define SQLITE_SCHEMA      17   /* The database schema changed */  | 
440  |  | #define SQLITE_TOOBIG      18   /* String or BLOB exceeds size limit */  | 
441  |  | #define SQLITE_CONSTRAINT  19   /* Abort due to constraint violation */  | 
442  |  | #define SQLITE_MISMATCH    20   /* Data type mismatch */  | 
443  |  | #define SQLITE_MISUSE      21   /* Library used incorrectly */  | 
444  |  | #define SQLITE_NOLFS       22   /* Uses OS features not supported on host */  | 
445  |  | #define SQLITE_AUTH        23   /* Authorization denied */  | 
446  |  | #define SQLITE_FORMAT      24   /* Not used */  | 
447  |  | #define SQLITE_RANGE       25   /* 2nd parameter to sqlite3_bind out of range */  | 
448  |  | #define SQLITE_NOTADB      26   /* File opened that is not a database file */  | 
449  |  | #define SQLITE_NOTICE      27   /* Notifications from sqlite3_log() */  | 
450  |  | #define SQLITE_WARNING     28   /* Warnings from sqlite3_log() */  | 
451  |  | #define SQLITE_ROW         100  /* sqlite3_step() has another row ready */  | 
452  |  | #define SQLITE_DONE        101  /* sqlite3_step() has finished executing */  | 
453  |  | /* end-of-error-codes */  | 
454  |  |  | 
455  |  | /*  | 
456  |  | ** CAPI3REF: Extended Result Codes  | 
457  |  | ** KEYWORDS: {extended result code definitions} | 
458  |  | **  | 
459  |  | ** In its default configuration, SQLite API routines return one of 30 integer  | 
460  |  | ** [result codes].  However, experience has shown that many of  | 
461  |  | ** these result codes are too coarse-grained.  They do not provide as  | 
462  |  | ** much information about problems as programmers might like.  In an effort to  | 
463  |  | ** address this, newer versions of SQLite (version 3.3.8 [dateof:3.3.8]  | 
464  |  | ** and later) include  | 
465  |  | ** support for additional result codes that provide more detailed information  | 
466  |  | ** about errors. These [extended result codes] are enabled or disabled  | 
467  |  | ** on a per database connection basis using the  | 
468  |  | ** [sqlite3_extended_result_codes()] API.  Or, the extended code for  | 
469  |  | ** the most recent error can be obtained using  | 
470  |  | ** [sqlite3_extended_errcode()].  | 
471  |  | */  | 
472  |  | #define SQLITE_ERROR_MISSING_COLLSEQ   (SQLITE_ERROR | (1<<8))  | 
473  |  | #define SQLITE_ERROR_RETRY             (SQLITE_ERROR | (2<<8))  | 
474  |  | #define SQLITE_ERROR_SNAPSHOT          (SQLITE_ERROR | (3<<8))  | 
475  |  | #define SQLITE_IOERR_READ              (SQLITE_IOERR | (1<<8))  | 
476  |  | #define SQLITE_IOERR_SHORT_READ        (SQLITE_IOERR | (2<<8))  | 
477  |  | #define SQLITE_IOERR_WRITE             (SQLITE_IOERR | (3<<8))  | 
478  |  | #define SQLITE_IOERR_FSYNC             (SQLITE_IOERR | (4<<8))  | 
479  |  | #define SQLITE_IOERR_DIR_FSYNC         (SQLITE_IOERR | (5<<8))  | 
480  |  | #define SQLITE_IOERR_TRUNCATE          (SQLITE_IOERR | (6<<8))  | 
481  |  | #define SQLITE_IOERR_FSTAT             (SQLITE_IOERR | (7<<8))  | 
482  |  | #define SQLITE_IOERR_UNLOCK            (SQLITE_IOERR | (8<<8))  | 
483  |  | #define SQLITE_IOERR_RDLOCK            (SQLITE_IOERR | (9<<8))  | 
484  |  | #define SQLITE_IOERR_DELETE            (SQLITE_IOERR | (10<<8))  | 
485  |  | #define SQLITE_IOERR_BLOCKED           (SQLITE_IOERR | (11<<8))  | 
486  |  | #define SQLITE_IOERR_NOMEM             (SQLITE_IOERR | (12<<8))  | 
487  |  | #define SQLITE_IOERR_ACCESS            (SQLITE_IOERR | (13<<8))  | 
488  |  | #define SQLITE_IOERR_CHECKRESERVEDLOCK (SQLITE_IOERR | (14<<8))  | 
489  |  | #define SQLITE_IOERR_LOCK              (SQLITE_IOERR | (15<<8))  | 
490  |  | #define SQLITE_IOERR_CLOSE             (SQLITE_IOERR | (16<<8))  | 
491  |  | #define SQLITE_IOERR_DIR_CLOSE         (SQLITE_IOERR | (17<<8))  | 
492  |  | #define SQLITE_IOERR_SHMOPEN           (SQLITE_IOERR | (18<<8))  | 
493  |  | #define SQLITE_IOERR_SHMSIZE           (SQLITE_IOERR | (19<<8))  | 
494  |  | #define SQLITE_IOERR_SHMLOCK           (SQLITE_IOERR | (20<<8))  | 
495  |  | #define SQLITE_IOERR_SHMMAP            (SQLITE_IOERR | (21<<8))  | 
496  |  | #define SQLITE_IOERR_SEEK              (SQLITE_IOERR | (22<<8))  | 
497  |  | #define SQLITE_IOERR_DELETE_NOENT      (SQLITE_IOERR | (23<<8))  | 
498  |  | #define SQLITE_IOERR_MMAP              (SQLITE_IOERR | (24<<8))  | 
499  |  | #define SQLITE_IOERR_GETTEMPPATH       (SQLITE_IOERR | (25<<8))  | 
500  |  | #define SQLITE_IOERR_CONVPATH          (SQLITE_IOERR | (26<<8))  | 
501  |  | #define SQLITE_IOERR_VNODE             (SQLITE_IOERR | (27<<8))  | 
502  |  | #define SQLITE_IOERR_AUTH              (SQLITE_IOERR | (28<<8))  | 
503  |  | #define SQLITE_IOERR_BEGIN_ATOMIC      (SQLITE_IOERR | (29<<8))  | 
504  |  | #define SQLITE_IOERR_COMMIT_ATOMIC     (SQLITE_IOERR | (30<<8))  | 
505  |  | #define SQLITE_IOERR_ROLLBACK_ATOMIC   (SQLITE_IOERR | (31<<8))  | 
506  |  | #define SQLITE_IOERR_DATA              (SQLITE_IOERR | (32<<8))  | 
507  |  | #define SQLITE_LOCKED_SHAREDCACHE      (SQLITE_LOCKED |  (1<<8))  | 
508  |  | #define SQLITE_LOCKED_VTAB             (SQLITE_LOCKED |  (2<<8))  | 
509  |  | #define SQLITE_BUSY_RECOVERY           (SQLITE_BUSY   |  (1<<8))  | 
510  |  | #define SQLITE_BUSY_SNAPSHOT           (SQLITE_BUSY   |  (2<<8))  | 
511  |  | #define SQLITE_BUSY_TIMEOUT            (SQLITE_BUSY   |  (3<<8))  | 
512  |  | #define SQLITE_CANTOPEN_NOTEMPDIR      (SQLITE_CANTOPEN | (1<<8))  | 
513  |  | #define SQLITE_CANTOPEN_ISDIR          (SQLITE_CANTOPEN | (2<<8))  | 
514  |  | #define SQLITE_CANTOPEN_FULLPATH       (SQLITE_CANTOPEN | (3<<8))  | 
515  |  | #define SQLITE_CANTOPEN_CONVPATH       (SQLITE_CANTOPEN | (4<<8))  | 
516  |  | #define SQLITE_CANTOPEN_DIRTYWAL       (SQLITE_CANTOPEN | (5<<8)) /* Not Used */  | 
517  |  | #define SQLITE_CANTOPEN_SYMLINK        (SQLITE_CANTOPEN | (6<<8))  | 
518  |  | #define SQLITE_CORRUPT_VTAB            (SQLITE_CORRUPT | (1<<8))  | 
519  |  | #define SQLITE_CORRUPT_SEQUENCE        (SQLITE_CORRUPT | (2<<8))  | 
520  |  | #define SQLITE_CORRUPT_INDEX           (SQLITE_CORRUPT | (3<<8))  | 
521  |  | #define SQLITE_READONLY_RECOVERY       (SQLITE_READONLY | (1<<8))  | 
522  |  | #define SQLITE_READONLY_CANTLOCK       (SQLITE_READONLY | (2<<8))  | 
523  |  | #define SQLITE_READONLY_ROLLBACK       (SQLITE_READONLY | (3<<8))  | 
524  |  | #define SQLITE_READONLY_DBMOVED        (SQLITE_READONLY | (4<<8))  | 
525  |  | #define SQLITE_READONLY_CANTINIT       (SQLITE_READONLY | (5<<8))  | 
526  |  | #define SQLITE_READONLY_DIRECTORY      (SQLITE_READONLY | (6<<8))  | 
527  |  | #define SQLITE_ABORT_ROLLBACK          (SQLITE_ABORT | (2<<8))  | 
528  |  | #define SQLITE_CONSTRAINT_CHECK        (SQLITE_CONSTRAINT | (1<<8))  | 
529  |  | #define SQLITE_CONSTRAINT_COMMITHOOK   (SQLITE_CONSTRAINT | (2<<8))  | 
530  |  | #define SQLITE_CONSTRAINT_FOREIGNKEY   (SQLITE_CONSTRAINT | (3<<8))  | 
531  |  | #define SQLITE_CONSTRAINT_FUNCTION     (SQLITE_CONSTRAINT | (4<<8))  | 
532  |  | #define SQLITE_CONSTRAINT_NOTNULL      (SQLITE_CONSTRAINT | (5<<8))  | 
533  |  | #define SQLITE_CONSTRAINT_PRIMARYKEY   (SQLITE_CONSTRAINT | (6<<8))  | 
534  |  | #define SQLITE_CONSTRAINT_TRIGGER      (SQLITE_CONSTRAINT | (7<<8))  | 
535  |  | #define SQLITE_CONSTRAINT_UNIQUE       (SQLITE_CONSTRAINT | (8<<8))  | 
536  |  | #define SQLITE_CONSTRAINT_VTAB         (SQLITE_CONSTRAINT | (9<<8))  | 
537  |  | #define SQLITE_CONSTRAINT_ROWID        (SQLITE_CONSTRAINT |(10<<8))  | 
538  |  | #define SQLITE_CONSTRAINT_PINNED       (SQLITE_CONSTRAINT |(11<<8))  | 
539  |  | #define SQLITE_NOTICE_RECOVER_WAL      (SQLITE_NOTICE | (1<<8))  | 
540  |  | #define SQLITE_NOTICE_RECOVER_ROLLBACK (SQLITE_NOTICE | (2<<8))  | 
541  |  | #define SQLITE_WARNING_AUTOINDEX       (SQLITE_WARNING | (1<<8))  | 
542  |  | #define SQLITE_AUTH_USER               (SQLITE_AUTH | (1<<8))  | 
543  |  | #define SQLITE_OK_LOAD_PERMANENTLY     (SQLITE_OK | (1<<8))  | 
544  |  | #define SQLITE_OK_SYMLINK              (SQLITE_OK | (2<<8))  | 
545  |  |  | 
546  |  | /*  | 
547  |  | ** CAPI3REF: Flags For File Open Operations  | 
548  |  | **  | 
549  |  | ** These bit values are intended for use in the  | 
550  |  | ** 3rd parameter to the [sqlite3_open_v2()] interface and  | 
551  |  | ** in the 4th parameter to the [sqlite3_vfs.xOpen] method.  | 
552  |  | */  | 
553  |  | #define SQLITE_OPEN_READONLY         0x00000001  /* Ok for sqlite3_open_v2() */  | 
554  | 20.2k  | #define SQLITE_OPEN_READWRITE        0x00000002  /* Ok for sqlite3_open_v2() */  | 
555  | 20.2k  | #define SQLITE_OPEN_CREATE           0x00000004  /* Ok for sqlite3_open_v2() */  | 
556  |  | #define SQLITE_OPEN_DELETEONCLOSE    0x00000008  /* VFS only */  | 
557  |  | #define SQLITE_OPEN_EXCLUSIVE        0x00000010  /* VFS only */  | 
558  |  | #define SQLITE_OPEN_AUTOPROXY        0x00000020  /* VFS only */  | 
559  |  | #define SQLITE_OPEN_URI              0x00000040  /* Ok for sqlite3_open_v2() */  | 
560  | 20.2k  | #define SQLITE_OPEN_MEMORY           0x00000080  /* Ok for sqlite3_open_v2() */  | 
561  |  | #define SQLITE_OPEN_MAIN_DB          0x00000100  /* VFS only */  | 
562  |  | #define SQLITE_OPEN_TEMP_DB          0x00000200  /* VFS only */  | 
563  |  | #define SQLITE_OPEN_TRANSIENT_DB     0x00000400  /* VFS only */  | 
564  |  | #define SQLITE_OPEN_MAIN_JOURNAL     0x00000800  /* VFS only */  | 
565  |  | #define SQLITE_OPEN_TEMP_JOURNAL     0x00001000  /* VFS only */  | 
566  |  | #define SQLITE_OPEN_SUBJOURNAL       0x00002000  /* VFS only */  | 
567  |  | #define SQLITE_OPEN_SUPER_JOURNAL    0x00004000  /* VFS only */  | 
568  |  | #define SQLITE_OPEN_NOMUTEX          0x00008000  /* Ok for sqlite3_open_v2() */  | 
569  |  | #define SQLITE_OPEN_FULLMUTEX        0x00010000  /* Ok for sqlite3_open_v2() */  | 
570  |  | #define SQLITE_OPEN_SHAREDCACHE      0x00020000  /* Ok for sqlite3_open_v2() */  | 
571  |  | #define SQLITE_OPEN_PRIVATECACHE     0x00040000  /* Ok for sqlite3_open_v2() */  | 
572  |  | #define SQLITE_OPEN_WAL              0x00080000  /* VFS only */  | 
573  |  | #define SQLITE_OPEN_NOFOLLOW         0x01000000  /* Ok for sqlite3_open_v2() */  | 
574  |  |  | 
575  |  | /* Reserved:                         0x00F00000 */  | 
576  |  | /* Legacy compatibility: */  | 
577  |  | #define SQLITE_OPEN_MASTER_JOURNAL   0x00004000  /* VFS only */  | 
578  |  |  | 
579  |  |  | 
580  |  | /*  | 
581  |  | ** CAPI3REF: Device Characteristics  | 
582  |  | **  | 
583  |  | ** The xDeviceCharacteristics method of the [sqlite3_io_methods]  | 
584  |  | ** object returns an integer which is a vector of these  | 
585  |  | ** bit values expressing I/O characteristics of the mass storage  | 
586  |  | ** device that holds the file that the [sqlite3_io_methods]  | 
587  |  | ** refers to.  | 
588  |  | **  | 
589  |  | ** The SQLITE_IOCAP_ATOMIC property means that all writes of  | 
590  |  | ** any size are atomic.  The SQLITE_IOCAP_ATOMICnnn values  | 
591  |  | ** mean that writes of blocks that are nnn bytes in size and  | 
592  |  | ** are aligned to an address which is an integer multiple of  | 
593  |  | ** nnn are atomic.  The SQLITE_IOCAP_SAFE_APPEND value means  | 
594  |  | ** that when data is appended to a file, the data is appended  | 
595  |  | ** first then the size of the file is extended, never the other  | 
596  |  | ** way around.  The SQLITE_IOCAP_SEQUENTIAL property means that  | 
597  |  | ** information is written to disk in the same order as calls  | 
598  |  | ** to xWrite().  The SQLITE_IOCAP_POWERSAFE_OVERWRITE property means that  | 
599  |  | ** after reboot following a crash or power loss, the only bytes in a  | 
600  |  | ** file that were written at the application level might have changed  | 
601  |  | ** and that adjacent bytes, even bytes within the same sector are  | 
602  |  | ** guaranteed to be unchanged.  The SQLITE_IOCAP_UNDELETABLE_WHEN_OPEN  | 
603  |  | ** flag indicates that a file cannot be deleted when open.  The  | 
604  |  | ** SQLITE_IOCAP_IMMUTABLE flag indicates that the file is on  | 
605  |  | ** read-only media and cannot be changed even by processes with  | 
606  |  | ** elevated privileges.  | 
607  |  | **  | 
608  |  | ** The SQLITE_IOCAP_BATCH_ATOMIC property means that the underlying  | 
609  |  | ** filesystem supports doing multiple write operations atomically when those  | 
610  |  | ** write operations are bracketed by [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE] and  | 
611  |  | ** [SQLITE_FCNTL_COMMIT_ATOMIC_WRITE].  | 
612  |  | */  | 
613  |  | #define SQLITE_IOCAP_ATOMIC                 0x00000001  | 
614  |  | #define SQLITE_IOCAP_ATOMIC512              0x00000002  | 
615  |  | #define SQLITE_IOCAP_ATOMIC1K               0x00000004  | 
616  |  | #define SQLITE_IOCAP_ATOMIC2K               0x00000008  | 
617  |  | #define SQLITE_IOCAP_ATOMIC4K               0x00000010  | 
618  |  | #define SQLITE_IOCAP_ATOMIC8K               0x00000020  | 
619  |  | #define SQLITE_IOCAP_ATOMIC16K              0x00000040  | 
620  |  | #define SQLITE_IOCAP_ATOMIC32K              0x00000080  | 
621  |  | #define SQLITE_IOCAP_ATOMIC64K              0x00000100  | 
622  |  | #define SQLITE_IOCAP_SAFE_APPEND            0x00000200  | 
623  |  | #define SQLITE_IOCAP_SEQUENTIAL             0x00000400  | 
624  |  | #define SQLITE_IOCAP_UNDELETABLE_WHEN_OPEN  0x00000800  | 
625  |  | #define SQLITE_IOCAP_POWERSAFE_OVERWRITE    0x00001000  | 
626  |  | #define SQLITE_IOCAP_IMMUTABLE              0x00002000  | 
627  |  | #define SQLITE_IOCAP_BATCH_ATOMIC           0x00004000  | 
628  |  |  | 
629  |  | /*  | 
630  |  | ** CAPI3REF: File Locking Levels  | 
631  |  | **  | 
632  |  | ** SQLite uses one of these integer values as the second  | 
633  |  | ** argument to calls it makes to the xLock() and xUnlock() methods  | 
634  |  | ** of an [sqlite3_io_methods] object.  | 
635  |  | */  | 
636  |  | #define SQLITE_LOCK_NONE          0  | 
637  |  | #define SQLITE_LOCK_SHARED        1  | 
638  |  | #define SQLITE_LOCK_RESERVED      2  | 
639  |  | #define SQLITE_LOCK_PENDING       3  | 
640  |  | #define SQLITE_LOCK_EXCLUSIVE     4  | 
641  |  |  | 
642  |  | /*  | 
643  |  | ** CAPI3REF: Synchronization Type Flags  | 
644  |  | **  | 
645  |  | ** When SQLite invokes the xSync() method of an  | 
646  |  | ** [sqlite3_io_methods] object it uses a combination of  | 
647  |  | ** these integer values as the second argument.  | 
648  |  | **  | 
649  |  | ** When the SQLITE_SYNC_DATAONLY flag is used, it means that the  | 
650  |  | ** sync operation only needs to flush data to mass storage.  Inode  | 
651  |  | ** information need not be flushed. If the lower four bits of the flag  | 
652  |  | ** equal SQLITE_SYNC_NORMAL, that means to use normal fsync() semantics.  | 
653  |  | ** If the lower four bits equal SQLITE_SYNC_FULL, that means  | 
654  |  | ** to use Mac OS X style fullsync instead of fsync().  | 
655  |  | **  | 
656  |  | ** Do not confuse the SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL flags  | 
657  |  | ** with the [PRAGMA synchronous]=NORMAL and [PRAGMA synchronous]=FULL  | 
658  |  | ** settings.  The [synchronous pragma] determines when calls to the  | 
659  |  | ** xSync VFS method occur and applies uniformly across all platforms.  | 
660  |  | ** The SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL flags determine how  | 
661  |  | ** energetic or rigorous or forceful the sync operations are and  | 
662  |  | ** only make a difference on Mac OSX for the default SQLite code.  | 
663  |  | ** (Third-party VFS implementations might also make the distinction  | 
664  |  | ** between SQLITE_SYNC_NORMAL and SQLITE_SYNC_FULL, but among the  | 
665  |  | ** operating systems natively supported by SQLite, only Mac OSX  | 
666  |  | ** cares about the difference.)  | 
667  |  | */  | 
668  |  | #define SQLITE_SYNC_NORMAL        0x00002  | 
669  |  | #define SQLITE_SYNC_FULL          0x00003  | 
670  |  | #define SQLITE_SYNC_DATAONLY      0x00010  | 
671  |  |  | 
672  |  | /*  | 
673  |  | ** CAPI3REF: OS Interface Open File Handle  | 
674  |  | **  | 
675  |  | ** An [sqlite3_file] object represents an open file in the  | 
676  |  | ** [sqlite3_vfs | OS interface layer].  Individual OS interface  | 
677  |  | ** implementations will  | 
678  |  | ** want to subclass this object by appending additional fields  | 
679  |  | ** for their own use.  The pMethods entry is a pointer to an  | 
680  |  | ** [sqlite3_io_methods] object that defines methods for performing  | 
681  |  | ** I/O operations on the open file.  | 
682  |  | */  | 
683  |  | typedef struct sqlite3_file sqlite3_file;  | 
684  |  | struct sqlite3_file { | 
685  |  |   const struct sqlite3_io_methods *pMethods;  /* Methods for an open file */  | 
686  |  | };  | 
687  |  |  | 
688  |  | /*  | 
689  |  | ** CAPI3REF: OS Interface File Virtual Methods Object  | 
690  |  | **  | 
691  |  | ** Every file opened by the [sqlite3_vfs.xOpen] method populates an  | 
692  |  | ** [sqlite3_file] object (or, more commonly, a subclass of the  | 
693  |  | ** [sqlite3_file] object) with a pointer to an instance of this object.  | 
694  |  | ** This object defines the methods used to perform various operations  | 
695  |  | ** against the open file represented by the [sqlite3_file] object.  | 
696  |  | **  | 
697  |  | ** If the [sqlite3_vfs.xOpen] method sets the sqlite3_file.pMethods element  | 
698  |  | ** to a non-NULL pointer, then the sqlite3_io_methods.xClose method  | 
699  |  | ** may be invoked even if the [sqlite3_vfs.xOpen] reported that it failed.  The  | 
700  |  | ** only way to prevent a call to xClose following a failed [sqlite3_vfs.xOpen]  | 
701  |  | ** is for the [sqlite3_vfs.xOpen] to set the sqlite3_file.pMethods element  | 
702  |  | ** to NULL.  | 
703  |  | **  | 
704  |  | ** The flags argument to xSync may be one of [SQLITE_SYNC_NORMAL] or  | 
705  |  | ** [SQLITE_SYNC_FULL].  The first choice is the normal fsync().  | 
706  |  | ** The second choice is a Mac OS X style fullsync.  The [SQLITE_SYNC_DATAONLY]  | 
707  |  | ** flag may be ORed in to indicate that only the data of the file  | 
708  |  | ** and not its inode needs to be synced.  | 
709  |  | **  | 
710  |  | ** The integer values to xLock() and xUnlock() are one of  | 
711  |  | ** <ul>  | 
712  |  | ** <li> [SQLITE_LOCK_NONE],  | 
713  |  | ** <li> [SQLITE_LOCK_SHARED],  | 
714  |  | ** <li> [SQLITE_LOCK_RESERVED],  | 
715  |  | ** <li> [SQLITE_LOCK_PENDING], or  | 
716  |  | ** <li> [SQLITE_LOCK_EXCLUSIVE].  | 
717  |  | ** </ul>  | 
718  |  | ** xLock() increases the lock. xUnlock() decreases the lock.  | 
719  |  | ** The xCheckReservedLock() method checks whether any database connection,  | 
720  |  | ** either in this process or in some other process, is holding a RESERVED,  | 
721  |  | ** PENDING, or EXCLUSIVE lock on the file.  It returns true  | 
722  |  | ** if such a lock exists and false otherwise.  | 
723  |  | **  | 
724  |  | ** The xFileControl() method is a generic interface that allows custom  | 
725  |  | ** VFS implementations to directly control an open file using the  | 
726  |  | ** [sqlite3_file_control()] interface.  The second "op" argument is an  | 
727  |  | ** integer opcode.  The third argument is a generic pointer intended to  | 
728  |  | ** point to a structure that may contain arguments or space in which to  | 
729  |  | ** write return values.  Potential uses for xFileControl() might be  | 
730  |  | ** functions to enable blocking locks with timeouts, to change the  | 
731  |  | ** locking strategy (for example to use dot-file locks), to inquire  | 
732  |  | ** about the status of a lock, or to break stale locks.  The SQLite  | 
733  |  | ** core reserves all opcodes less than 100 for its own use.  | 
734  |  | ** A [file control opcodes | list of opcodes] less than 100 is available.  | 
735  |  | ** Applications that define a custom xFileControl method should use opcodes  | 
736  |  | ** greater than 100 to avoid conflicts.  VFS implementations should  | 
737  |  | ** return [SQLITE_NOTFOUND] for file control opcodes that they do not  | 
738  |  | ** recognize.  | 
739  |  | **  | 
740  |  | ** The xSectorSize() method returns the sector size of the  | 
741  |  | ** device that underlies the file.  The sector size is the  | 
742  |  | ** minimum write that can be performed without disturbing  | 
743  |  | ** other bytes in the file.  The xDeviceCharacteristics()  | 
744  |  | ** method returns a bit vector describing behaviors of the  | 
745  |  | ** underlying device:  | 
746  |  | **  | 
747  |  | ** <ul>  | 
748  |  | ** <li> [SQLITE_IOCAP_ATOMIC]  | 
749  |  | ** <li> [SQLITE_IOCAP_ATOMIC512]  | 
750  |  | ** <li> [SQLITE_IOCAP_ATOMIC1K]  | 
751  |  | ** <li> [SQLITE_IOCAP_ATOMIC2K]  | 
752  |  | ** <li> [SQLITE_IOCAP_ATOMIC4K]  | 
753  |  | ** <li> [SQLITE_IOCAP_ATOMIC8K]  | 
754  |  | ** <li> [SQLITE_IOCAP_ATOMIC16K]  | 
755  |  | ** <li> [SQLITE_IOCAP_ATOMIC32K]  | 
756  |  | ** <li> [SQLITE_IOCAP_ATOMIC64K]  | 
757  |  | ** <li> [SQLITE_IOCAP_SAFE_APPEND]  | 
758  |  | ** <li> [SQLITE_IOCAP_SEQUENTIAL]  | 
759  |  | ** <li> [SQLITE_IOCAP_UNDELETABLE_WHEN_OPEN]  | 
760  |  | ** <li> [SQLITE_IOCAP_POWERSAFE_OVERWRITE]  | 
761  |  | ** <li> [SQLITE_IOCAP_IMMUTABLE]  | 
762  |  | ** <li> [SQLITE_IOCAP_BATCH_ATOMIC]  | 
763  |  | ** </ul>  | 
764  |  | **  | 
765  |  | ** The SQLITE_IOCAP_ATOMIC property means that all writes of  | 
766  |  | ** any size are atomic.  The SQLITE_IOCAP_ATOMICnnn values  | 
767  |  | ** mean that writes of blocks that are nnn bytes in size and  | 
768  |  | ** are aligned to an address which is an integer multiple of  | 
769  |  | ** nnn are atomic.  The SQLITE_IOCAP_SAFE_APPEND value means  | 
770  |  | ** that when data is appended to a file, the data is appended  | 
771  |  | ** first then the size of the file is extended, never the other  | 
772  |  | ** way around.  The SQLITE_IOCAP_SEQUENTIAL property means that  | 
773  |  | ** information is written to disk in the same order as calls  | 
774  |  | ** to xWrite().  | 
775  |  | **  | 
776  |  | ** If xRead() returns SQLITE_IOERR_SHORT_READ it must also fill  | 
777  |  | ** in the unread portions of the buffer with zeros.  A VFS that  | 
778  |  | ** fails to zero-fill short reads might seem to work.  However,  | 
779  |  | ** failure to zero-fill short reads will eventually lead to  | 
780  |  | ** database corruption.  | 
781  |  | */  | 
782  |  | typedef struct sqlite3_io_methods sqlite3_io_methods;  | 
783  |  | struct sqlite3_io_methods { | 
784  |  |   int iVersion;  | 
785  |  |   int (*xClose)(sqlite3_file*);  | 
786  |  |   int (*xRead)(sqlite3_file*, void*, int iAmt, sqlite3_int64 iOfst);  | 
787  |  |   int (*xWrite)(sqlite3_file*, const void*, int iAmt, sqlite3_int64 iOfst);  | 
788  |  |   int (*xTruncate)(sqlite3_file*, sqlite3_int64 size);  | 
789  |  |   int (*xSync)(sqlite3_file*, int flags);  | 
790  |  |   int (*xFileSize)(sqlite3_file*, sqlite3_int64 *pSize);  | 
791  |  |   int (*xLock)(sqlite3_file*, int);  | 
792  |  |   int (*xUnlock)(sqlite3_file*, int);  | 
793  |  |   int (*xCheckReservedLock)(sqlite3_file*, int *pResOut);  | 
794  |  |   int (*xFileControl)(sqlite3_file*, int op, void *pArg);  | 
795  |  |   int (*xSectorSize)(sqlite3_file*);  | 
796  |  |   int (*xDeviceCharacteristics)(sqlite3_file*);  | 
797  |  |   /* Methods above are valid for version 1 */  | 
798  |  |   int (*xShmMap)(sqlite3_file*, int iPg, int pgsz, int, void volatile**);  | 
799  |  |   int (*xShmLock)(sqlite3_file*, int offset, int n, int flags);  | 
800  |  |   void (*xShmBarrier)(sqlite3_file*);  | 
801  |  |   int (*xShmUnmap)(sqlite3_file*, int deleteFlag);  | 
802  |  |   /* Methods above are valid for version 2 */  | 
803  |  |   int (*xFetch)(sqlite3_file*, sqlite3_int64 iOfst, int iAmt, void **pp);  | 
804  |  |   int (*xUnfetch)(sqlite3_file*, sqlite3_int64 iOfst, void *p);  | 
805  |  |   /* Methods above are valid for version 3 */  | 
806  |  |   /* Additional methods may be added in future releases */  | 
807  |  | };  | 
808  |  |  | 
809  |  | /*  | 
810  |  | ** CAPI3REF: Standard File Control Opcodes  | 
811  |  | ** KEYWORDS: {file control opcodes} {file control opcode} | 
812  |  | **  | 
813  |  | ** These integer constants are opcodes for the xFileControl method  | 
814  |  | ** of the [sqlite3_io_methods] object and for the [sqlite3_file_control()]  | 
815  |  | ** interface.  | 
816  |  | **  | 
817  |  | ** <ul>  | 
818  |  | ** <li>[[SQLITE_FCNTL_LOCKSTATE]]  | 
819  |  | ** The [SQLITE_FCNTL_LOCKSTATE] opcode is used for debugging.  This  | 
820  |  | ** opcode causes the xFileControl method to write the current state of  | 
821  |  | ** the lock (one of [SQLITE_LOCK_NONE], [SQLITE_LOCK_SHARED],  | 
822  |  | ** [SQLITE_LOCK_RESERVED], [SQLITE_LOCK_PENDING], or [SQLITE_LOCK_EXCLUSIVE])  | 
823  |  | ** into an integer that the pArg argument points to. This capability  | 
824  |  | ** is used during testing and is only available when the SQLITE_TEST  | 
825  |  | ** compile-time option is used.  | 
826  |  | **  | 
827  |  | ** <li>[[SQLITE_FCNTL_SIZE_HINT]]  | 
828  |  | ** The [SQLITE_FCNTL_SIZE_HINT] opcode is used by SQLite to give the VFS  | 
829  |  | ** layer a hint of how large the database file will grow to be during the  | 
830  |  | ** current transaction.  This hint is not guaranteed to be accurate but it  | 
831  |  | ** is often close.  The underlying VFS might choose to preallocate database  | 
832  |  | ** file space based on this hint in order to help writes to the database  | 
833  |  | ** file run faster.  | 
834  |  | **  | 
835  |  | ** <li>[[SQLITE_FCNTL_SIZE_LIMIT]]  | 
836  |  | ** The [SQLITE_FCNTL_SIZE_LIMIT] opcode is used by in-memory VFS that  | 
837  |  | ** implements [sqlite3_deserialize()] to set an upper bound on the size  | 
838  |  | ** of the in-memory database.  The argument is a pointer to a [sqlite3_int64].  | 
839  |  | ** If the integer pointed to is negative, then it is filled in with the  | 
840  |  | ** current limit.  Otherwise the limit is set to the larger of the value  | 
841  |  | ** of the integer pointed to and the current database size.  The integer  | 
842  |  | ** pointed to is set to the new limit.  | 
843  |  | **  | 
844  |  | ** <li>[[SQLITE_FCNTL_CHUNK_SIZE]]  | 
845  |  | ** The [SQLITE_FCNTL_CHUNK_SIZE] opcode is used to request that the VFS  | 
846  |  | ** extends and truncates the database file in chunks of a size specified  | 
847  |  | ** by the user. The fourth argument to [sqlite3_file_control()] should  | 
848  |  | ** point to an integer (type int) containing the new chunk-size to use  | 
849  |  | ** for the nominated database. Allocating database file space in large  | 
850  |  | ** chunks (say 1MB at a time), may reduce file-system fragmentation and  | 
851  |  | ** improve performance on some systems.  | 
852  |  | **  | 
853  |  | ** <li>[[SQLITE_FCNTL_FILE_POINTER]]  | 
854  |  | ** The [SQLITE_FCNTL_FILE_POINTER] opcode is used to obtain a pointer  | 
855  |  | ** to the [sqlite3_file] object associated with a particular database  | 
856  |  | ** connection.  See also [SQLITE_FCNTL_JOURNAL_POINTER].  | 
857  |  | **  | 
858  |  | ** <li>[[SQLITE_FCNTL_JOURNAL_POINTER]]  | 
859  |  | ** The [SQLITE_FCNTL_JOURNAL_POINTER] opcode is used to obtain a pointer  | 
860  |  | ** to the [sqlite3_file] object associated with the journal file (either  | 
861  |  | ** the [rollback journal] or the [write-ahead log]) for a particular database  | 
862  |  | ** connection.  See also [SQLITE_FCNTL_FILE_POINTER].  | 
863  |  | **  | 
864  |  | ** <li>[[SQLITE_FCNTL_SYNC_OMITTED]]  | 
865  |  | ** No longer in use.  | 
866  |  | **  | 
867  |  | ** <li>[[SQLITE_FCNTL_SYNC]]  | 
868  |  | ** The [SQLITE_FCNTL_SYNC] opcode is generated internally by SQLite and  | 
869  |  | ** sent to the VFS immediately before the xSync method is invoked on a  | 
870  |  | ** database file descriptor. Or, if the xSync method is not invoked  | 
871  |  | ** because the user has configured SQLite with  | 
872  |  | ** [PRAGMA synchronous | PRAGMA synchronous=OFF] it is invoked in place  | 
873  |  | ** of the xSync method. In most cases, the pointer argument passed with  | 
874  |  | ** this file-control is NULL. However, if the database file is being synced  | 
875  |  | ** as part of a multi-database commit, the argument points to a nul-terminated  | 
876  |  | ** string containing the transactions super-journal file name. VFSes that  | 
877  |  | ** do not need this signal should silently ignore this opcode. Applications  | 
878  |  | ** should not call [sqlite3_file_control()] with this opcode as doing so may  | 
879  |  | ** disrupt the operation of the specialized VFSes that do require it.  | 
880  |  | **  | 
881  |  | ** <li>[[SQLITE_FCNTL_COMMIT_PHASETWO]]  | 
882  |  | ** The [SQLITE_FCNTL_COMMIT_PHASETWO] opcode is generated internally by SQLite  | 
883  |  | ** and sent to the VFS after a transaction has been committed immediately  | 
884  |  | ** but before the database is unlocked. VFSes that do not need this signal  | 
885  |  | ** should silently ignore this opcode. Applications should not call  | 
886  |  | ** [sqlite3_file_control()] with this opcode as doing so may disrupt the  | 
887  |  | ** operation of the specialized VFSes that do require it.  | 
888  |  | **  | 
889  |  | ** <li>[[SQLITE_FCNTL_WIN32_AV_RETRY]]  | 
890  |  | ** ^The [SQLITE_FCNTL_WIN32_AV_RETRY] opcode is used to configure automatic  | 
891  |  | ** retry counts and intervals for certain disk I/O operations for the  | 
892  |  | ** windows [VFS] in order to provide robustness in the presence of  | 
893  |  | ** anti-virus programs.  By default, the windows VFS will retry file read,  | 
894  |  | ** file write, and file delete operations up to 10 times, with a delay  | 
895  |  | ** of 25 milliseconds before the first retry and with the delay increasing  | 
896  |  | ** by an additional 25 milliseconds with each subsequent retry.  This  | 
897  |  | ** opcode allows these two values (10 retries and 25 milliseconds of delay)  | 
898  |  | ** to be adjusted.  The values are changed for all database connections  | 
899  |  | ** within the same process.  The argument is a pointer to an array of two  | 
900  |  | ** integers where the first integer is the new retry count and the second  | 
901  |  | ** integer is the delay.  If either integer is negative, then the setting  | 
902  |  | ** is not changed but instead the prior value of that setting is written  | 
903  |  | ** into the array entry, allowing the current retry settings to be  | 
904  |  | ** interrogated.  The zDbName parameter is ignored.  | 
905  |  | **  | 
906  |  | ** <li>[[SQLITE_FCNTL_PERSIST_WAL]]  | 
907  |  | ** ^The [SQLITE_FCNTL_PERSIST_WAL] opcode is used to set or query the  | 
908  |  | ** persistent [WAL | Write Ahead Log] setting.  By default, the auxiliary  | 
909  |  | ** write ahead log ([WAL file]) and shared memory  | 
910  |  | ** files used for transaction control  | 
911  |  | ** are automatically deleted when the latest connection to the database  | 
912  |  | ** closes.  Setting persistent WAL mode causes those files to persist after  | 
913  |  | ** close.  Persisting the files is useful when other processes that do not  | 
914  |  | ** have write permission on the directory containing the database file want  | 
915  |  | ** to read the database file, as the WAL and shared memory files must exist  | 
916  |  | ** in order for the database to be readable.  The fourth parameter to  | 
917  |  | ** [sqlite3_file_control()] for this opcode should be a pointer to an integer.  | 
918  |  | ** That integer is 0 to disable persistent WAL mode or 1 to enable persistent  | 
919  |  | ** WAL mode.  If the integer is -1, then it is overwritten with the current  | 
920  |  | ** WAL persistence setting.  | 
921  |  | **  | 
922  |  | ** <li>[[SQLITE_FCNTL_POWERSAFE_OVERWRITE]]  | 
923  |  | ** ^The [SQLITE_FCNTL_POWERSAFE_OVERWRITE] opcode is used to set or query the  | 
924  |  | ** persistent "powersafe-overwrite" or "PSOW" setting.  The PSOW setting  | 
925  |  | ** determines the [SQLITE_IOCAP_POWERSAFE_OVERWRITE] bit of the  | 
926  |  | ** xDeviceCharacteristics methods. The fourth parameter to  | 
927  |  | ** [sqlite3_file_control()] for this opcode should be a pointer to an integer.  | 
928  |  | ** That integer is 0 to disable zero-damage mode or 1 to enable zero-damage  | 
929  |  | ** mode.  If the integer is -1, then it is overwritten with the current  | 
930  |  | ** zero-damage mode setting.  | 
931  |  | **  | 
932  |  | ** <li>[[SQLITE_FCNTL_OVERWRITE]]  | 
933  |  | ** ^The [SQLITE_FCNTL_OVERWRITE] opcode is invoked by SQLite after opening  | 
934  |  | ** a write transaction to indicate that, unless it is rolled back for some  | 
935  |  | ** reason, the entire database file will be overwritten by the current  | 
936  |  | ** transaction. This is used by VACUUM operations.  | 
937  |  | **  | 
938  |  | ** <li>[[SQLITE_FCNTL_VFSNAME]]  | 
939  |  | ** ^The [SQLITE_FCNTL_VFSNAME] opcode can be used to obtain the names of  | 
940  |  | ** all [VFSes] in the VFS stack.  The names are of all VFS shims and the  | 
941  |  | ** final bottom-level VFS are written into memory obtained from  | 
942  |  | ** [sqlite3_malloc()] and the result is stored in the char* variable  | 
943  |  | ** that the fourth parameter of [sqlite3_file_control()] points to.  | 
944  |  | ** The caller is responsible for freeing the memory when done.  As with  | 
945  |  | ** all file-control actions, there is no guarantee that this will actually  | 
946  |  | ** do anything.  Callers should initialize the char* variable to a NULL  | 
947  |  | ** pointer in case this file-control is not implemented.  This file-control  | 
948  |  | ** is intended for diagnostic use only.  | 
949  |  | **  | 
950  |  | ** <li>[[SQLITE_FCNTL_VFS_POINTER]]  | 
951  |  | ** ^The [SQLITE_FCNTL_VFS_POINTER] opcode finds a pointer to the top-level  | 
952  |  | ** [VFSes] currently in use.  ^(The argument X in  | 
953  |  | ** sqlite3_file_control(db,SQLITE_FCNTL_VFS_POINTER,X) must be  | 
954  |  | ** of type "[sqlite3_vfs] **".  This opcodes will set *X  | 
955  |  | ** to a pointer to the top-level VFS.)^  | 
956  |  | ** ^When there are multiple VFS shims in the stack, this opcode finds the  | 
957  |  | ** upper-most shim only.  | 
958  |  | **  | 
959  |  | ** <li>[[SQLITE_FCNTL_PRAGMA]]  | 
960  |  | ** ^Whenever a [PRAGMA] statement is parsed, an [SQLITE_FCNTL_PRAGMA]  | 
961  |  | ** file control is sent to the open [sqlite3_file] object corresponding  | 
962  |  | ** to the database file to which the pragma statement refers. ^The argument  | 
963  |  | ** to the [SQLITE_FCNTL_PRAGMA] file control is an array of  | 
964  |  | ** pointers to strings (char**) in which the second element of the array  | 
965  |  | ** is the name of the pragma and the third element is the argument to the  | 
966  |  | ** pragma or NULL if the pragma has no argument.  ^The handler for an  | 
967  |  | ** [SQLITE_FCNTL_PRAGMA] file control can optionally make the first element  | 
968  |  | ** of the char** argument point to a string obtained from [sqlite3_mprintf()]  | 
969  |  | ** or the equivalent and that string will become the result of the pragma or  | 
970  |  | ** the error message if the pragma fails. ^If the  | 
971  |  | ** [SQLITE_FCNTL_PRAGMA] file control returns [SQLITE_NOTFOUND], then normal  | 
972  |  | ** [PRAGMA] processing continues.  ^If the [SQLITE_FCNTL_PRAGMA]  | 
973  |  | ** file control returns [SQLITE_OK], then the parser assumes that the  | 
974  |  | ** VFS has handled the PRAGMA itself and the parser generates a no-op  | 
975  |  | ** prepared statement if result string is NULL, or that returns a copy  | 
976  |  | ** of the result string if the string is non-NULL.  | 
977  |  | ** ^If the [SQLITE_FCNTL_PRAGMA] file control returns  | 
978  |  | ** any result code other than [SQLITE_OK] or [SQLITE_NOTFOUND], that means  | 
979  |  | ** that the VFS encountered an error while handling the [PRAGMA] and the  | 
980  |  | ** compilation of the PRAGMA fails with an error.  ^The [SQLITE_FCNTL_PRAGMA]  | 
981  |  | ** file control occurs at the beginning of pragma statement analysis and so  | 
982  |  | ** it is able to override built-in [PRAGMA] statements.  | 
983  |  | **  | 
984  |  | ** <li>[[SQLITE_FCNTL_BUSYHANDLER]]  | 
985  |  | ** ^The [SQLITE_FCNTL_BUSYHANDLER]  | 
986  |  | ** file-control may be invoked by SQLite on the database file handle  | 
987  |  | ** shortly after it is opened in order to provide a custom VFS with access  | 
988  |  | ** to the connection's busy-handler callback. The argument is of type (void**)  | 
989  |  | ** - an array of two (void *) values. The first (void *) actually points  | 
990  |  | ** to a function of type (int (*)(void *)). In order to invoke the connection's  | 
991  |  | ** busy-handler, this function should be invoked with the second (void *) in  | 
992  |  | ** the array as the only argument. If it returns non-zero, then the operation  | 
993  |  | ** should be retried. If it returns zero, the custom VFS should abandon the  | 
994  |  | ** current operation.  | 
995  |  | **  | 
996  |  | ** <li>[[SQLITE_FCNTL_TEMPFILENAME]]  | 
997  |  | ** ^Applications can invoke the [SQLITE_FCNTL_TEMPFILENAME] file-control  | 
998  |  | ** to have SQLite generate a  | 
999  |  | ** temporary filename using the same algorithm that is followed to generate  | 
1000  |  | ** temporary filenames for TEMP tables and other internal uses.  The  | 
1001  |  | ** argument should be a char** which will be filled with the filename  | 
1002  |  | ** written into memory obtained from [sqlite3_malloc()].  The caller should  | 
1003  |  | ** invoke [sqlite3_free()] on the result to avoid a memory leak.  | 
1004  |  | **  | 
1005  |  | ** <li>[[SQLITE_FCNTL_MMAP_SIZE]]  | 
1006  |  | ** The [SQLITE_FCNTL_MMAP_SIZE] file control is used to query or set the  | 
1007  |  | ** maximum number of bytes that will be used for memory-mapped I/O.  | 
1008  |  | ** The argument is a pointer to a value of type sqlite3_int64 that  | 
1009  |  | ** is an advisory maximum number of bytes in the file to memory map.  The  | 
1010  |  | ** pointer is overwritten with the old value.  The limit is not changed if  | 
1011  |  | ** the value originally pointed to is negative, and so the current limit  | 
1012  |  | ** can be queried by passing in a pointer to a negative number.  This  | 
1013  |  | ** file-control is used internally to implement [PRAGMA mmap_size].  | 
1014  |  | **  | 
1015  |  | ** <li>[[SQLITE_FCNTL_TRACE]]  | 
1016  |  | ** The [SQLITE_FCNTL_TRACE] file control provides advisory information  | 
1017  |  | ** to the VFS about what the higher layers of the SQLite stack are doing.  | 
1018  |  | ** This file control is used by some VFS activity tracing [shims].  | 
1019  |  | ** The argument is a zero-terminated string.  Higher layers in the  | 
1020  |  | ** SQLite stack may generate instances of this file control if  | 
1021  |  | ** the [SQLITE_USE_FCNTL_TRACE] compile-time option is enabled.  | 
1022  |  | **  | 
1023  |  | ** <li>[[SQLITE_FCNTL_HAS_MOVED]]  | 
1024  |  | ** The [SQLITE_FCNTL_HAS_MOVED] file control interprets its argument as a  | 
1025  |  | ** pointer to an integer and it writes a boolean into that integer depending  | 
1026  |  | ** on whether or not the file has been renamed, moved, or deleted since it  | 
1027  |  | ** was first opened.  | 
1028  |  | **  | 
1029  |  | ** <li>[[SQLITE_FCNTL_WIN32_GET_HANDLE]]  | 
1030  |  | ** The [SQLITE_FCNTL_WIN32_GET_HANDLE] opcode can be used to obtain the  | 
1031  |  | ** underlying native file handle associated with a file handle.  This file  | 
1032  |  | ** control interprets its argument as a pointer to a native file handle and  | 
1033  |  | ** writes the resulting value there.  | 
1034  |  | **  | 
1035  |  | ** <li>[[SQLITE_FCNTL_WIN32_SET_HANDLE]]  | 
1036  |  | ** The [SQLITE_FCNTL_WIN32_SET_HANDLE] opcode is used for debugging.  This  | 
1037  |  | ** opcode causes the xFileControl method to swap the file handle with the one  | 
1038  |  | ** pointed to by the pArg argument.  This capability is used during testing  | 
1039  |  | ** and only needs to be supported when SQLITE_TEST is defined.  | 
1040  |  | **  | 
1041  |  | ** <li>[[SQLITE_FCNTL_WAL_BLOCK]]  | 
1042  |  | ** The [SQLITE_FCNTL_WAL_BLOCK] is a signal to the VFS layer that it might  | 
1043  |  | ** be advantageous to block on the next WAL lock if the lock is not immediately  | 
1044  |  | ** available.  The WAL subsystem issues this signal during rare  | 
1045  |  | ** circumstances in order to fix a problem with priority inversion.  | 
1046  |  | ** Applications should <em>not</em> use this file-control.  | 
1047  |  | **  | 
1048  |  | ** <li>[[SQLITE_FCNTL_ZIPVFS]]  | 
1049  |  | ** The [SQLITE_FCNTL_ZIPVFS] opcode is implemented by zipvfs only. All other  | 
1050  |  | ** VFS should return SQLITE_NOTFOUND for this opcode.  | 
1051  |  | **  | 
1052  |  | ** <li>[[SQLITE_FCNTL_RBU]]  | 
1053  |  | ** The [SQLITE_FCNTL_RBU] opcode is implemented by the special VFS used by  | 
1054  |  | ** the RBU extension only.  All other VFS should return SQLITE_NOTFOUND for  | 
1055  |  | ** this opcode.  | 
1056  |  | **  | 
1057  |  | ** <li>[[SQLITE_FCNTL_BEGIN_ATOMIC_WRITE]]  | 
1058  |  | ** If the [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE] opcode returns SQLITE_OK, then  | 
1059  |  | ** the file descriptor is placed in "batch write mode", which  | 
1060  |  | ** means all subsequent write operations will be deferred and done  | 
1061  |  | ** atomically at the next [SQLITE_FCNTL_COMMIT_ATOMIC_WRITE].  Systems  | 
1062  |  | ** that do not support batch atomic writes will return SQLITE_NOTFOUND.  | 
1063  |  | ** ^Following a successful SQLITE_FCNTL_BEGIN_ATOMIC_WRITE and prior to  | 
1064  |  | ** the closing [SQLITE_FCNTL_COMMIT_ATOMIC_WRITE] or  | 
1065  |  | ** [SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE], SQLite will make  | 
1066  |  | ** no VFS interface calls on the same [sqlite3_file] file descriptor  | 
1067  |  | ** except for calls to the xWrite method and the xFileControl method  | 
1068  |  | ** with [SQLITE_FCNTL_SIZE_HINT].  | 
1069  |  | **  | 
1070  |  | ** <li>[[SQLITE_FCNTL_COMMIT_ATOMIC_WRITE]]  | 
1071  |  | ** The [SQLITE_FCNTL_COMMIT_ATOMIC_WRITE] opcode causes all write  | 
1072  |  | ** operations since the previous successful call to  | 
1073  |  | ** [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE] to be performed atomically.  | 
1074  |  | ** This file control returns [SQLITE_OK] if and only if the writes were  | 
1075  |  | ** all performed successfully and have been committed to persistent storage.  | 
1076  |  | ** ^Regardless of whether or not it is successful, this file control takes  | 
1077  |  | ** the file descriptor out of batch write mode so that all subsequent  | 
1078  |  | ** write operations are independent.  | 
1079  |  | ** ^SQLite will never invoke SQLITE_FCNTL_COMMIT_ATOMIC_WRITE without  | 
1080  |  | ** a prior successful call to [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE].  | 
1081  |  | **  | 
1082  |  | ** <li>[[SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE]]  | 
1083  |  | ** The [SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE] opcode causes all write  | 
1084  |  | ** operations since the previous successful call to  | 
1085  |  | ** [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE] to be rolled back.  | 
1086  |  | ** ^This file control takes the file descriptor out of batch write mode  | 
1087  |  | ** so that all subsequent write operations are independent.  | 
1088  |  | ** ^SQLite will never invoke SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE without  | 
1089  |  | ** a prior successful call to [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE].  | 
1090  |  | **  | 
1091  |  | ** <li>[[SQLITE_FCNTL_LOCK_TIMEOUT]]  | 
1092  |  | ** The [SQLITE_FCNTL_LOCK_TIMEOUT] opcode is used to configure a VFS  | 
1093  |  | ** to block for up to M milliseconds before failing when attempting to  | 
1094  |  | ** obtain a file lock using the xLock or xShmLock methods of the VFS.  | 
1095  |  | ** The parameter is a pointer to a 32-bit signed integer that contains  | 
1096  |  | ** the value that M is to be set to. Before returning, the 32-bit signed  | 
1097  |  | ** integer is overwritten with the previous value of M.  | 
1098  |  | **  | 
1099  |  | ** <li>[[SQLITE_FCNTL_DATA_VERSION]]  | 
1100  |  | ** The [SQLITE_FCNTL_DATA_VERSION] opcode is used to detect changes to  | 
1101  |  | ** a database file.  The argument is a pointer to a 32-bit unsigned integer.  | 
1102  |  | ** The "data version" for the pager is written into the pointer.  The  | 
1103  |  | ** "data version" changes whenever any change occurs to the corresponding  | 
1104  |  | ** database file, either through SQL statements on the same database  | 
1105  |  | ** connection or through transactions committed by separate database  | 
1106  |  | ** connections possibly in other processes. The [sqlite3_total_changes()]  | 
1107  |  | ** interface can be used to find if any database on the connection has changed,  | 
1108  |  | ** but that interface responds to changes on TEMP as well as MAIN and does  | 
1109  |  | ** not provide a mechanism to detect changes to MAIN only.  Also, the  | 
1110  |  | ** [sqlite3_total_changes()] interface responds to internal changes only and  | 
1111  |  | ** omits changes made by other database connections.  The  | 
1112  |  | ** [PRAGMA data_version] command provides a mechanism to detect changes to  | 
1113  |  | ** a single attached database that occur due to other database connections,  | 
1114  |  | ** but omits changes implemented by the database connection on which it is  | 
1115  |  | ** called.  This file control is the only mechanism to detect changes that  | 
1116  |  | ** happen either internally or externally and that are associated with  | 
1117  |  | ** a particular attached database.  | 
1118  |  | **  | 
1119  |  | ** <li>[[SQLITE_FCNTL_CKPT_START]]  | 
1120  |  | ** The [SQLITE_FCNTL_CKPT_START] opcode is invoked from within a checkpoint  | 
1121  |  | ** in wal mode before the client starts to copy pages from the wal  | 
1122  |  | ** file to the database file.  | 
1123  |  | **  | 
1124  |  | ** <li>[[SQLITE_FCNTL_CKPT_DONE]]  | 
1125  |  | ** The [SQLITE_FCNTL_CKPT_DONE] opcode is invoked from within a checkpoint  | 
1126  |  | ** in wal mode after the client has finished copying pages from the wal  | 
1127  |  | ** file to the database file, but before the *-shm file is updated to  | 
1128  |  | ** record the fact that the pages have been checkpointed.  | 
1129  |  | ** </ul>  | 
1130  |  | */  | 
1131  |  | #define SQLITE_FCNTL_LOCKSTATE               1  | 
1132  |  | #define SQLITE_FCNTL_GET_LOCKPROXYFILE       2  | 
1133  |  | #define SQLITE_FCNTL_SET_LOCKPROXYFILE       3  | 
1134  |  | #define SQLITE_FCNTL_LAST_ERRNO              4  | 
1135  |  | #define SQLITE_FCNTL_SIZE_HINT               5  | 
1136  |  | #define SQLITE_FCNTL_CHUNK_SIZE              6  | 
1137  |  | #define SQLITE_FCNTL_FILE_POINTER            7  | 
1138  |  | #define SQLITE_FCNTL_SYNC_OMITTED            8  | 
1139  |  | #define SQLITE_FCNTL_WIN32_AV_RETRY          9  | 
1140  |  | #define SQLITE_FCNTL_PERSIST_WAL            10  | 
1141  |  | #define SQLITE_FCNTL_OVERWRITE              11  | 
1142  |  | #define SQLITE_FCNTL_VFSNAME                12  | 
1143  |  | #define SQLITE_FCNTL_POWERSAFE_OVERWRITE    13  | 
1144  |  | #define SQLITE_FCNTL_PRAGMA                 14  | 
1145  |  | #define SQLITE_FCNTL_BUSYHANDLER            15  | 
1146  |  | #define SQLITE_FCNTL_TEMPFILENAME           16  | 
1147  |  | #define SQLITE_FCNTL_MMAP_SIZE              18  | 
1148  |  | #define SQLITE_FCNTL_TRACE                  19  | 
1149  |  | #define SQLITE_FCNTL_HAS_MOVED              20  | 
1150  |  | #define SQLITE_FCNTL_SYNC                   21  | 
1151  |  | #define SQLITE_FCNTL_COMMIT_PHASETWO        22  | 
1152  |  | #define SQLITE_FCNTL_WIN32_SET_HANDLE       23  | 
1153  |  | #define SQLITE_FCNTL_WAL_BLOCK              24  | 
1154  |  | #define SQLITE_FCNTL_ZIPVFS                 25  | 
1155  |  | #define SQLITE_FCNTL_RBU                    26  | 
1156  |  | #define SQLITE_FCNTL_VFS_POINTER            27  | 
1157  |  | #define SQLITE_FCNTL_JOURNAL_POINTER        28  | 
1158  |  | #define SQLITE_FCNTL_WIN32_GET_HANDLE       29  | 
1159  |  | #define SQLITE_FCNTL_PDB                    30  | 
1160  |  | #define SQLITE_FCNTL_BEGIN_ATOMIC_WRITE     31  | 
1161  |  | #define SQLITE_FCNTL_COMMIT_ATOMIC_WRITE    32  | 
1162  |  | #define SQLITE_FCNTL_ROLLBACK_ATOMIC_WRITE  33  | 
1163  |  | #define SQLITE_FCNTL_LOCK_TIMEOUT           34  | 
1164  |  | #define SQLITE_FCNTL_DATA_VERSION           35  | 
1165  |  | #define SQLITE_FCNTL_SIZE_LIMIT             36  | 
1166  |  | #define SQLITE_FCNTL_CKPT_DONE              37  | 
1167  |  | #define SQLITE_FCNTL_RESERVE_BYTES          38  | 
1168  |  | #define SQLITE_FCNTL_CKPT_START             39  | 
1169  |  |  | 
1170  |  | /* deprecated names */  | 
1171  |  | #define SQLITE_GET_LOCKPROXYFILE      SQLITE_FCNTL_GET_LOCKPROXYFILE  | 
1172  |  | #define SQLITE_SET_LOCKPROXYFILE      SQLITE_FCNTL_SET_LOCKPROXYFILE  | 
1173  |  | #define SQLITE_LAST_ERRNO             SQLITE_FCNTL_LAST_ERRNO  | 
1174  |  |  | 
1175  |  |  | 
1176  |  | /*  | 
1177  |  | ** CAPI3REF: Mutex Handle  | 
1178  |  | **  | 
1179  |  | ** The mutex module within SQLite defines [sqlite3_mutex] to be an  | 
1180  |  | ** abstract type for a mutex object.  The SQLite core never looks  | 
1181  |  | ** at the internal representation of an [sqlite3_mutex].  It only  | 
1182  |  | ** deals with pointers to the [sqlite3_mutex] object.  | 
1183  |  | **  | 
1184  |  | ** Mutexes are created using [sqlite3_mutex_alloc()].  | 
1185  |  | */  | 
1186  |  | typedef struct sqlite3_mutex sqlite3_mutex;  | 
1187  |  |  | 
1188  |  | /*  | 
1189  |  | ** CAPI3REF: Loadable Extension Thunk  | 
1190  |  | **  | 
1191  |  | ** A pointer to the opaque sqlite3_api_routines structure is passed as  | 
1192  |  | ** the third parameter to entry points of [loadable extensions].  This  | 
1193  |  | ** structure must be typedefed in order to work around compiler warnings  | 
1194  |  | ** on some platforms.  | 
1195  |  | */  | 
1196  |  | typedef struct sqlite3_api_routines sqlite3_api_routines;  | 
1197  |  |  | 
1198  |  | /*  | 
1199  |  | ** CAPI3REF: OS Interface Object  | 
1200  |  | **  | 
1201  |  | ** An instance of the sqlite3_vfs object defines the interface between  | 
1202  |  | ** the SQLite core and the underlying operating system.  The "vfs"  | 
1203  |  | ** in the name of the object stands for "virtual file system".  See  | 
1204  |  | ** the [VFS | VFS documentation] for further information.  | 
1205  |  | **  | 
1206  |  | ** The VFS interface is sometimes extended by adding new methods onto  | 
1207  |  | ** the end.  Each time such an extension occurs, the iVersion field  | 
1208  |  | ** is incremented.  The iVersion value started out as 1 in  | 
1209  |  | ** SQLite [version 3.5.0] on [dateof:3.5.0], then increased to 2  | 
1210  |  | ** with SQLite [version 3.7.0] on [dateof:3.7.0], and then increased  | 
1211  |  | ** to 3 with SQLite [version 3.7.6] on [dateof:3.7.6].  Additional fields  | 
1212  |  | ** may be appended to the sqlite3_vfs object and the iVersion value  | 
1213  |  | ** may increase again in future versions of SQLite.  | 
1214  |  | ** Note that due to an oversight, the structure  | 
1215  |  | ** of the sqlite3_vfs object changed in the transition from  | 
1216  |  | ** SQLite [version 3.5.9] to [version 3.6.0] on [dateof:3.6.0]  | 
1217  |  | ** and yet the iVersion field was not increased.  | 
1218  |  | **  | 
1219  |  | ** The szOsFile field is the size of the subclassed [sqlite3_file]  | 
1220  |  | ** structure used by this VFS.  mxPathname is the maximum length of  | 
1221  |  | ** a pathname in this VFS.  | 
1222  |  | **  | 
1223  |  | ** Registered sqlite3_vfs objects are kept on a linked list formed by  | 
1224  |  | ** the pNext pointer.  The [sqlite3_vfs_register()]  | 
1225  |  | ** and [sqlite3_vfs_unregister()] interfaces manage this list  | 
1226  |  | ** in a thread-safe way.  The [sqlite3_vfs_find()] interface  | 
1227  |  | ** searches the list.  Neither the application code nor the VFS  | 
1228  |  | ** implementation should use the pNext pointer.  | 
1229  |  | **  | 
1230  |  | ** The pNext field is the only field in the sqlite3_vfs  | 
1231  |  | ** structure that SQLite will ever modify.  SQLite will only access  | 
1232  |  | ** or modify this field while holding a particular static mutex.  | 
1233  |  | ** The application should never modify anything within the sqlite3_vfs  | 
1234  |  | ** object once the object has been registered.  | 
1235  |  | **  | 
1236  |  | ** The zName field holds the name of the VFS module.  The name must  | 
1237  |  | ** be unique across all VFS modules.  | 
1238  |  | **  | 
1239  |  | ** [[sqlite3_vfs.xOpen]]  | 
1240  |  | ** ^SQLite guarantees that the zFilename parameter to xOpen  | 
1241  |  | ** is either a NULL pointer or string obtained  | 
1242  |  | ** from xFullPathname() with an optional suffix added.  | 
1243  |  | ** ^If a suffix is added to the zFilename parameter, it will  | 
1244  |  | ** consist of a single "-" character followed by no more than  | 
1245  |  | ** 11 alphanumeric and/or "-" characters.  | 
1246  |  | ** ^SQLite further guarantees that  | 
1247  |  | ** the string will be valid and unchanged until xClose() is  | 
1248  |  | ** called. Because of the previous sentence,  | 
1249  |  | ** the [sqlite3_file] can safely store a pointer to the  | 
1250  |  | ** filename if it needs to remember the filename for some reason.  | 
1251  |  | ** If the zFilename parameter to xOpen is a NULL pointer then xOpen  | 
1252  |  | ** must invent its own temporary name for the file.  ^Whenever the  | 
1253  |  | ** xFilename parameter is NULL it will also be the case that the  | 
1254  |  | ** flags parameter will include [SQLITE_OPEN_DELETEONCLOSE].  | 
1255  |  | **  | 
1256  |  | ** The flags argument to xOpen() includes all bits set in  | 
1257  |  | ** the flags argument to [sqlite3_open_v2()].  Or if [sqlite3_open()]  | 
1258  |  | ** or [sqlite3_open16()] is used, then flags includes at least  | 
1259  |  | ** [SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE].  | 
1260  |  | ** If xOpen() opens a file read-only then it sets *pOutFlags to  | 
1261  |  | ** include [SQLITE_OPEN_READONLY].  Other bits in *pOutFlags may be set.  | 
1262  |  | **  | 
1263  |  | ** ^(SQLite will also add one of the following flags to the xOpen()  | 
1264  |  | ** call, depending on the object being opened:  | 
1265  |  | **  | 
1266  |  | ** <ul>  | 
1267  |  | ** <li>  [SQLITE_OPEN_MAIN_DB]  | 
1268  |  | ** <li>  [SQLITE_OPEN_MAIN_JOURNAL]  | 
1269  |  | ** <li>  [SQLITE_OPEN_TEMP_DB]  | 
1270  |  | ** <li>  [SQLITE_OPEN_TEMP_JOURNAL]  | 
1271  |  | ** <li>  [SQLITE_OPEN_TRANSIENT_DB]  | 
1272  |  | ** <li>  [SQLITE_OPEN_SUBJOURNAL]  | 
1273  |  | ** <li>  [SQLITE_OPEN_SUPER_JOURNAL]  | 
1274  |  | ** <li>  [SQLITE_OPEN_WAL]  | 
1275  |  | ** </ul>)^  | 
1276  |  | **  | 
1277  |  | ** The file I/O implementation can use the object type flags to  | 
1278  |  | ** change the way it deals with files.  For example, an application  | 
1279  |  | ** that does not care about crash recovery or rollback might make  | 
1280  |  | ** the open of a journal file a no-op.  Writes to this journal would  | 
1281  |  | ** also be no-ops, and any attempt to read the journal would return  | 
1282  |  | ** SQLITE_IOERR.  Or the implementation might recognize that a database  | 
1283  |  | ** file will be doing page-aligned sector reads and writes in a random  | 
1284  |  | ** order and set up its I/O subsystem accordingly.  | 
1285  |  | **  | 
1286  |  | ** SQLite might also add one of the following flags to the xOpen method:  | 
1287  |  | **  | 
1288  |  | ** <ul>  | 
1289  |  | ** <li> [SQLITE_OPEN_DELETEONCLOSE]  | 
1290  |  | ** <li> [SQLITE_OPEN_EXCLUSIVE]  | 
1291  |  | ** </ul>  | 
1292  |  | **  | 
1293  |  | ** The [SQLITE_OPEN_DELETEONCLOSE] flag means the file should be  | 
1294  |  | ** deleted when it is closed.  ^The [SQLITE_OPEN_DELETEONCLOSE]  | 
1295  |  | ** will be set for TEMP databases and their journals, transient  | 
1296  |  | ** databases, and subjournals.  | 
1297  |  | **  | 
1298  |  | ** ^The [SQLITE_OPEN_EXCLUSIVE] flag is always used in conjunction  | 
1299  |  | ** with the [SQLITE_OPEN_CREATE] flag, which are both directly  | 
1300  |  | ** analogous to the O_EXCL and O_CREAT flags of the POSIX open()  | 
1301  |  | ** API.  The SQLITE_OPEN_EXCLUSIVE flag, when paired with the  | 
1302  |  | ** SQLITE_OPEN_CREATE, is used to indicate that file should always  | 
1303  |  | ** be created, and that it is an error if it already exists.  | 
1304  |  | ** It is <i>not</i> used to indicate the file should be opened  | 
1305  |  | ** for exclusive access.  | 
1306  |  | **  | 
1307  |  | ** ^At least szOsFile bytes of memory are allocated by SQLite  | 
1308  |  | ** to hold the [sqlite3_file] structure passed as the third  | 
1309  |  | ** argument to xOpen.  The xOpen method does not have to  | 
1310  |  | ** allocate the structure; it should just fill it in.  Note that  | 
1311  |  | ** the xOpen method must set the sqlite3_file.pMethods to either  | 
1312  |  | ** a valid [sqlite3_io_methods] object or to NULL.  xOpen must do  | 
1313  |  | ** this even if the open fails.  SQLite expects that the sqlite3_file.pMethods  | 
1314  |  | ** element will be valid after xOpen returns regardless of the success  | 
1315  |  | ** or failure of the xOpen call.  | 
1316  |  | **  | 
1317  |  | ** [[sqlite3_vfs.xAccess]]  | 
1318  |  | ** ^The flags argument to xAccess() may be [SQLITE_ACCESS_EXISTS]  | 
1319  |  | ** to test for the existence of a file, or [SQLITE_ACCESS_READWRITE] to  | 
1320  |  | ** test whether a file is readable and writable, or [SQLITE_ACCESS_READ]  | 
1321  |  | ** to test whether a file is at least readable.  The SQLITE_ACCESS_READ  | 
1322  |  | ** flag is never actually used and is not implemented in the built-in  | 
1323  |  | ** VFSes of SQLite.  The file is named by the second argument and can be a  | 
1324  |  | ** directory. The xAccess method returns [SQLITE_OK] on success or some  | 
1325  |  | ** non-zero error code if there is an I/O error or if the name of  | 
1326  |  | ** the file given in the second argument is illegal.  If SQLITE_OK  | 
1327  |  | ** is returned, then non-zero or zero is written into *pResOut to indicate  | 
1328  |  | ** whether or not the file is accessible.  | 
1329  |  | **  | 
1330  |  | ** ^SQLite will always allocate at least mxPathname+1 bytes for the  | 
1331  |  | ** output buffer xFullPathname.  The exact size of the output buffer  | 
1332  |  | ** is also passed as a parameter to both  methods. If the output buffer  | 
1333  |  | ** is not large enough, [SQLITE_CANTOPEN] should be returned. Since this is  | 
1334  |  | ** handled as a fatal error by SQLite, vfs implementations should endeavor  | 
1335  |  | ** to prevent this by setting mxPathname to a sufficiently large value.  | 
1336  |  | **  | 
1337  |  | ** The xRandomness(), xSleep(), xCurrentTime(), and xCurrentTimeInt64()  | 
1338  |  | ** interfaces are not strictly a part of the filesystem, but they are  | 
1339  |  | ** included in the VFS structure for completeness.  | 
1340  |  | ** The xRandomness() function attempts to return nBytes bytes  | 
1341  |  | ** of good-quality randomness into zOut.  The return value is  | 
1342  |  | ** the actual number of bytes of randomness obtained.  | 
1343  |  | ** The xSleep() method causes the calling thread to sleep for at  | 
1344  |  | ** least the number of microseconds given.  ^The xCurrentTime()  | 
1345  |  | ** method returns a Julian Day Number for the current date and time as  | 
1346  |  | ** a floating point value.  | 
1347  |  | ** ^The xCurrentTimeInt64() method returns, as an integer, the Julian  | 
1348  |  | ** Day Number multiplied by 86400000 (the number of milliseconds in  | 
1349  |  | ** a 24-hour day).  | 
1350  |  | ** ^SQLite will use the xCurrentTimeInt64() method to get the current  | 
1351  |  | ** date and time if that method is available (if iVersion is 2 or  | 
1352  |  | ** greater and the function pointer is not NULL) and will fall back  | 
1353  |  | ** to xCurrentTime() if xCurrentTimeInt64() is unavailable.  | 
1354  |  | **  | 
1355  |  | ** ^The xSetSystemCall(), xGetSystemCall(), and xNestSystemCall() interfaces  | 
1356  |  | ** are not used by the SQLite core.  These optional interfaces are provided  | 
1357  |  | ** by some VFSes to facilitate testing of the VFS code. By overriding  | 
1358  |  | ** system calls with functions under its control, a test program can  | 
1359  |  | ** simulate faults and error conditions that would otherwise be difficult  | 
1360  |  | ** or impossible to induce.  The set of system calls that can be overridden  | 
1361  |  | ** varies from one VFS to another, and from one version of the same VFS to the  | 
1362  |  | ** next.  Applications that use these interfaces must be prepared for any  | 
1363  |  | ** or all of these interfaces to be NULL or for their behavior to change  | 
1364  |  | ** from one release to the next.  Applications must not attempt to access  | 
1365  |  | ** any of these methods if the iVersion of the VFS is less than 3.  | 
1366  |  | */  | 
1367  |  | typedef struct sqlite3_vfs sqlite3_vfs;  | 
1368  |  | typedef void (*sqlite3_syscall_ptr)(void);  | 
1369  |  | struct sqlite3_vfs { | 
1370  |  |   int iVersion;            /* Structure version number (currently 3) */  | 
1371  |  |   int szOsFile;            /* Size of subclassed sqlite3_file */  | 
1372  |  |   int mxPathname;          /* Maximum file pathname length */  | 
1373  |  |   sqlite3_vfs *pNext;      /* Next registered VFS */  | 
1374  |  |   const char *zName;       /* Name of this virtual file system */  | 
1375  |  |   void *pAppData;          /* Pointer to application-specific data */  | 
1376  |  |   int (*xOpen)(sqlite3_vfs*, const char *zName, sqlite3_file*,  | 
1377  |  |                int flags, int *pOutFlags);  | 
1378  |  |   int (*xDelete)(sqlite3_vfs*, const char *zName, int syncDir);  | 
1379  |  |   int (*xAccess)(sqlite3_vfs*, const char *zName, int flags, int *pResOut);  | 
1380  |  |   int (*xFullPathname)(sqlite3_vfs*, const char *zName, int nOut, char *zOut);  | 
1381  |  |   void *(*xDlOpen)(sqlite3_vfs*, const char *zFilename);  | 
1382  |  |   void (*xDlError)(sqlite3_vfs*, int nByte, char *zErrMsg);  | 
1383  |  |   void (*(*xDlSym)(sqlite3_vfs*,void*, const char *zSymbol))(void);  | 
1384  |  |   void (*xDlClose)(sqlite3_vfs*, void*);  | 
1385  |  |   int (*xRandomness)(sqlite3_vfs*, int nByte, char *zOut);  | 
1386  |  |   int (*xSleep)(sqlite3_vfs*, int microseconds);  | 
1387  |  |   int (*xCurrentTime)(sqlite3_vfs*, double*);  | 
1388  |  |   int (*xGetLastError)(sqlite3_vfs*, int, char *);  | 
1389  |  |   /*  | 
1390  |  |   ** The methods above are in version 1 of the sqlite_vfs object  | 
1391  |  |   ** definition.  Those that follow are added in version 2 or later  | 
1392  |  |   */  | 
1393  |  |   int (*xCurrentTimeInt64)(sqlite3_vfs*, sqlite3_int64*);  | 
1394  |  |   /*  | 
1395  |  |   ** The methods above are in versions 1 and 2 of the sqlite_vfs object.  | 
1396  |  |   ** Those below are for version 3 and greater.  | 
1397  |  |   */  | 
1398  |  |   int (*xSetSystemCall)(sqlite3_vfs*, const char *zName, sqlite3_syscall_ptr);  | 
1399  |  |   sqlite3_syscall_ptr (*xGetSystemCall)(sqlite3_vfs*, const char *zName);  | 
1400  |  |   const char *(*xNextSystemCall)(sqlite3_vfs*, const char *zName);  | 
1401  |  |   /*  | 
1402  |  |   ** The methods above are in versions 1 through 3 of the sqlite_vfs object.  | 
1403  |  |   ** New fields may be appended in future versions.  The iVersion  | 
1404  |  |   ** value will increment whenever this happens.  | 
1405  |  |   */  | 
1406  |  | };  | 
1407  |  |  | 
1408  |  | /*  | 
1409  |  | ** CAPI3REF: Flags for the xAccess VFS method  | 
1410  |  | **  | 
1411  |  | ** These integer constants can be used as the third parameter to  | 
1412  |  | ** the xAccess method of an [sqlite3_vfs] object.  They determine  | 
1413  |  | ** what kind of permissions the xAccess method is looking for.  | 
1414  |  | ** With SQLITE_ACCESS_EXISTS, the xAccess method  | 
1415  |  | ** simply checks whether the file exists.  | 
1416  |  | ** With SQLITE_ACCESS_READWRITE, the xAccess method  | 
1417  |  | ** checks whether the named directory is both readable and writable  | 
1418  |  | ** (in other words, if files can be added, removed, and renamed within  | 
1419  |  | ** the directory).  | 
1420  |  | ** The SQLITE_ACCESS_READWRITE constant is currently used only by the  | 
1421  |  | ** [temp_store_directory pragma], though this could change in a future  | 
1422  |  | ** release of SQLite.  | 
1423  |  | ** With SQLITE_ACCESS_READ, the xAccess method  | 
1424  |  | ** checks whether the file is readable.  The SQLITE_ACCESS_READ constant is  | 
1425  |  | ** currently unused, though it might be used in a future release of  | 
1426  |  | ** SQLite.  | 
1427  |  | */  | 
1428  |  | #define SQLITE_ACCESS_EXISTS    0  | 
1429  |  | #define SQLITE_ACCESS_READWRITE 1   /* Used by PRAGMA temp_store_directory */  | 
1430  |  | #define SQLITE_ACCESS_READ      2   /* Unused */  | 
1431  |  |  | 
1432  |  | /*  | 
1433  |  | ** CAPI3REF: Flags for the xShmLock VFS method  | 
1434  |  | **  | 
1435  |  | ** These integer constants define the various locking operations  | 
1436  |  | ** allowed by the xShmLock method of [sqlite3_io_methods].  The  | 
1437  |  | ** following are the only legal combinations of flags to the  | 
1438  |  | ** xShmLock method:  | 
1439  |  | **  | 
1440  |  | ** <ul>  | 
1441  |  | ** <li>  SQLITE_SHM_LOCK | SQLITE_SHM_SHARED  | 
1442  |  | ** <li>  SQLITE_SHM_LOCK | SQLITE_SHM_EXCLUSIVE  | 
1443  |  | ** <li>  SQLITE_SHM_UNLOCK | SQLITE_SHM_SHARED  | 
1444  |  | ** <li>  SQLITE_SHM_UNLOCK | SQLITE_SHM_EXCLUSIVE  | 
1445  |  | ** </ul>  | 
1446  |  | **  | 
1447  |  | ** When unlocking, the same SHARED or EXCLUSIVE flag must be supplied as  | 
1448  |  | ** was given on the corresponding lock.  | 
1449  |  | **  | 
1450  |  | ** The xShmLock method can transition between unlocked and SHARED or  | 
1451  |  | ** between unlocked and EXCLUSIVE.  It cannot transition between SHARED  | 
1452  |  | ** and EXCLUSIVE.  | 
1453  |  | */  | 
1454  |  | #define SQLITE_SHM_UNLOCK       1  | 
1455  |  | #define SQLITE_SHM_LOCK         2  | 
1456  |  | #define SQLITE_SHM_SHARED       4  | 
1457  |  | #define SQLITE_SHM_EXCLUSIVE    8  | 
1458  |  |  | 
1459  |  | /*  | 
1460  |  | ** CAPI3REF: Maximum xShmLock index  | 
1461  |  | **  | 
1462  |  | ** The xShmLock method on [sqlite3_io_methods] may use values  | 
1463  |  | ** between 0 and this upper bound as its "offset" argument.  | 
1464  |  | ** The SQLite core will never attempt to acquire or release a  | 
1465  |  | ** lock outside of this range  | 
1466  |  | */  | 
1467  |  | #define SQLITE_SHM_NLOCK        8  | 
1468  |  |  | 
1469  |  |  | 
1470  |  | /*  | 
1471  |  | ** CAPI3REF: Initialize The SQLite Library  | 
1472  |  | **  | 
1473  |  | ** ^The sqlite3_initialize() routine initializes the  | 
1474  |  | ** SQLite library.  ^The sqlite3_shutdown() routine  | 
1475  |  | ** deallocates any resources that were allocated by sqlite3_initialize().  | 
1476  |  | ** These routines are designed to aid in process initialization and  | 
1477  |  | ** shutdown on embedded systems.  Workstation applications using  | 
1478  |  | ** SQLite normally do not need to invoke either of these routines.  | 
1479  |  | **  | 
1480  |  | ** A call to sqlite3_initialize() is an "effective" call if it is  | 
1481  |  | ** the first time sqlite3_initialize() is invoked during the lifetime of  | 
1482  |  | ** the process, or if it is the first time sqlite3_initialize() is invoked  | 
1483  |  | ** following a call to sqlite3_shutdown().  ^(Only an effective call  | 
1484  |  | ** of sqlite3_initialize() does any initialization.  All other calls  | 
1485  |  | ** are harmless no-ops.)^  | 
1486  |  | **  | 
1487  |  | ** A call to sqlite3_shutdown() is an "effective" call if it is the first  | 
1488  |  | ** call to sqlite3_shutdown() since the last sqlite3_initialize().  ^(Only  | 
1489  |  | ** an effective call to sqlite3_shutdown() does any deinitialization.  | 
1490  |  | ** All other valid calls to sqlite3_shutdown() are harmless no-ops.)^  | 
1491  |  | **  | 
1492  |  | ** The sqlite3_initialize() interface is threadsafe, but sqlite3_shutdown()  | 
1493  |  | ** is not.  The sqlite3_shutdown() interface must only be called from a  | 
1494  |  | ** single thread.  All open [database connections] must be closed and all  | 
1495  |  | ** other SQLite resources must be deallocated prior to invoking  | 
1496  |  | ** sqlite3_shutdown().  | 
1497  |  | **  | 
1498  |  | ** Among other things, ^sqlite3_initialize() will invoke  | 
1499  |  | ** sqlite3_os_init().  Similarly, ^sqlite3_shutdown()  | 
1500  |  | ** will invoke sqlite3_os_end().  | 
1501  |  | **  | 
1502  |  | ** ^The sqlite3_initialize() routine returns [SQLITE_OK] on success.  | 
1503  |  | ** ^If for some reason, sqlite3_initialize() is unable to initialize  | 
1504  |  | ** the library (perhaps it is unable to allocate a needed resource such  | 
1505  |  | ** as a mutex) it returns an [error code] other than [SQLITE_OK].  | 
1506  |  | **  | 
1507  |  | ** ^The sqlite3_initialize() routine is called internally by many other  | 
1508  |  | ** SQLite interfaces so that an application usually does not need to  | 
1509  |  | ** invoke sqlite3_initialize() directly.  For example, [sqlite3_open()]  | 
1510  |  | ** calls sqlite3_initialize() so the SQLite library will be automatically  | 
1511  |  | ** initialized when [sqlite3_open()] is called if it has not be initialized  | 
1512  |  | ** already.  ^However, if SQLite is compiled with the [SQLITE_OMIT_AUTOINIT]  | 
1513  |  | ** compile-time option, then the automatic calls to sqlite3_initialize()  | 
1514  |  | ** are omitted and the application must call sqlite3_initialize() directly  | 
1515  |  | ** prior to using any other SQLite interface.  For maximum portability,  | 
1516  |  | ** it is recommended that applications always invoke sqlite3_initialize()  | 
1517  |  | ** directly prior to using any other SQLite interface.  Future releases  | 
1518  |  | ** of SQLite may require this.  In other words, the behavior exhibited  | 
1519  |  | ** when SQLite is compiled with [SQLITE_OMIT_AUTOINIT] might become the  | 
1520  |  | ** default behavior in some future release of SQLite.  | 
1521  |  | **  | 
1522  |  | ** The sqlite3_os_init() routine does operating-system specific  | 
1523  |  | ** initialization of the SQLite library.  The sqlite3_os_end()  | 
1524  |  | ** routine undoes the effect of sqlite3_os_init().  Typical tasks  | 
1525  |  | ** performed by these routines include allocation or deallocation  | 
1526  |  | ** of static resources, initialization of global variables,  | 
1527  |  | ** setting up a default [sqlite3_vfs] module, or setting up  | 
1528  |  | ** a default configuration using [sqlite3_config()].  | 
1529  |  | **  | 
1530  |  | ** The application should never invoke either sqlite3_os_init()  | 
1531  |  | ** or sqlite3_os_end() directly.  The application should only invoke  | 
1532  |  | ** sqlite3_initialize() and sqlite3_shutdown().  The sqlite3_os_init()  | 
1533  |  | ** interface is called automatically by sqlite3_initialize() and  | 
1534  |  | ** sqlite3_os_end() is called by sqlite3_shutdown().  Appropriate  | 
1535  |  | ** implementations for sqlite3_os_init() and sqlite3_os_end()  | 
1536  |  | ** are built into SQLite when it is compiled for Unix, Windows, or OS/2.  | 
1537  |  | ** When [custom builds | built for other platforms]  | 
1538  |  | ** (using the [SQLITE_OS_OTHER=1] compile-time  | 
1539  |  | ** option) the application must supply a suitable implementation for  | 
1540  |  | ** sqlite3_os_init() and sqlite3_os_end().  An application-supplied  | 
1541  |  | ** implementation of sqlite3_os_init() or sqlite3_os_end()  | 
1542  |  | ** must return [SQLITE_OK] on success and some other [error code] upon  | 
1543  |  | ** failure.  | 
1544  |  | */  | 
1545  |  | SQLITE_API int sqlite3_initialize(void);  | 
1546  |  | SQLITE_API int sqlite3_shutdown(void);  | 
1547  |  | SQLITE_API int sqlite3_os_init(void);  | 
1548  |  | SQLITE_API int sqlite3_os_end(void);  | 
1549  |  |  | 
1550  |  | /*  | 
1551  |  | ** CAPI3REF: Configuring The SQLite Library  | 
1552  |  | **  | 
1553  |  | ** The sqlite3_config() interface is used to make global configuration  | 
1554  |  | ** changes to SQLite in order to tune SQLite to the specific needs of  | 
1555  |  | ** the application.  The default configuration is recommended for most  | 
1556  |  | ** applications and so this routine is usually not necessary.  It is  | 
1557  |  | ** provided to support rare applications with unusual needs.  | 
1558  |  | **  | 
1559  |  | ** <b>The sqlite3_config() interface is not threadsafe. The application  | 
1560  |  | ** must ensure that no other SQLite interfaces are invoked by other  | 
1561  |  | ** threads while sqlite3_config() is running.</b>  | 
1562  |  | **  | 
1563  |  | ** The sqlite3_config() interface  | 
1564  |  | ** may only be invoked prior to library initialization using  | 
1565  |  | ** [sqlite3_initialize()] or after shutdown by [sqlite3_shutdown()].  | 
1566  |  | ** ^If sqlite3_config() is called after [sqlite3_initialize()] and before  | 
1567  |  | ** [sqlite3_shutdown()] then it will return SQLITE_MISUSE.  | 
1568  |  | ** Note, however, that ^sqlite3_config() can be called as part of the  | 
1569  |  | ** implementation of an application-defined [sqlite3_os_init()].  | 
1570  |  | **  | 
1571  |  | ** The first argument to sqlite3_config() is an integer  | 
1572  |  | ** [configuration option] that determines  | 
1573  |  | ** what property of SQLite is to be configured.  Subsequent arguments  | 
1574  |  | ** vary depending on the [configuration option]  | 
1575  |  | ** in the first argument.  | 
1576  |  | **  | 
1577  |  | ** ^When a configuration option is set, sqlite3_config() returns [SQLITE_OK].  | 
1578  |  | ** ^If the option is unknown or SQLite is unable to set the option  | 
1579  |  | ** then this routine returns a non-zero [error code].  | 
1580  |  | */  | 
1581  |  | SQLITE_API int sqlite3_config(int, ...);  | 
1582  |  |  | 
1583  |  | /*  | 
1584  |  | ** CAPI3REF: Configure database connections  | 
1585  |  | ** METHOD: sqlite3  | 
1586  |  | **  | 
1587  |  | ** The sqlite3_db_config() interface is used to make configuration  | 
1588  |  | ** changes to a [database connection].  The interface is similar to  | 
1589  |  | ** [sqlite3_config()] except that the changes apply to a single  | 
1590  |  | ** [database connection] (specified in the first argument).  | 
1591  |  | **  | 
1592  |  | ** The second argument to sqlite3_db_config(D,V,...)  is the  | 
1593  |  | ** [SQLITE_DBCONFIG_LOOKASIDE | configuration verb] - an integer code  | 
1594  |  | ** that indicates what aspect of the [database connection] is being configured.  | 
1595  |  | ** Subsequent arguments vary depending on the configuration verb.  | 
1596  |  | **  | 
1597  |  | ** ^Calls to sqlite3_db_config() return SQLITE_OK if and only if  | 
1598  |  | ** the call is considered successful.  | 
1599  |  | */  | 
1600  |  | SQLITE_API int sqlite3_db_config(sqlite3*, int op, ...);  | 
1601  |  |  | 
1602  |  | /*  | 
1603  |  | ** CAPI3REF: Memory Allocation Routines  | 
1604  |  | **  | 
1605  |  | ** An instance of this object defines the interface between SQLite  | 
1606  |  | ** and low-level memory allocation routines.  | 
1607  |  | **  | 
1608  |  | ** This object is used in only one place in the SQLite interface.  | 
1609  |  | ** A pointer to an instance of this object is the argument to  | 
1610  |  | ** [sqlite3_config()] when the configuration option is  | 
1611  |  | ** [SQLITE_CONFIG_MALLOC] or [SQLITE_CONFIG_GETMALLOC].  | 
1612  |  | ** By creating an instance of this object  | 
1613  |  | ** and passing it to [sqlite3_config]([SQLITE_CONFIG_MALLOC])  | 
1614  |  | ** during configuration, an application can specify an alternative  | 
1615  |  | ** memory allocation subsystem for SQLite to use for all of its  | 
1616  |  | ** dynamic memory needs.  | 
1617  |  | **  | 
1618  |  | ** Note that SQLite comes with several [built-in memory allocators]  | 
1619  |  | ** that are perfectly adequate for the overwhelming majority of applications  | 
1620  |  | ** and that this object is only useful to a tiny minority of applications  | 
1621  |  | ** with specialized memory allocation requirements.  This object is  | 
1622  |  | ** also used during testing of SQLite in order to specify an alternative  | 
1623  |  | ** memory allocator that simulates memory out-of-memory conditions in  | 
1624  |  | ** order to verify that SQLite recovers gracefully from such  | 
1625  |  | ** conditions.  | 
1626  |  | **  | 
1627  |  | ** The xMalloc, xRealloc, and xFree methods must work like the  | 
1628  |  | ** malloc(), realloc() and free() functions from the standard C library.  | 
1629  |  | ** ^SQLite guarantees that the second argument to  | 
1630  |  | ** xRealloc is always a value returned by a prior call to xRoundup.  | 
1631  |  | **  | 
1632  |  | ** xSize should return the allocated size of a memory allocation  | 
1633  |  | ** previously obtained from xMalloc or xRealloc.  The allocated size  | 
1634  |  | ** is always at least as big as the requested size but may be larger.  | 
1635  |  | **  | 
1636  |  | ** The xRoundup method returns what would be the allocated size of  | 
1637  |  | ** a memory allocation given a particular requested size.  Most memory  | 
1638  |  | ** allocators round up memory allocations at least to the next multiple  | 
1639  |  | ** of 8.  Some allocators round up to a larger multiple or to a power of 2.  | 
1640  |  | ** Every memory allocation request coming in through [sqlite3_malloc()]  | 
1641  |  | ** or [sqlite3_realloc()] first calls xRoundup.  If xRoundup returns 0,  | 
1642  |  | ** that causes the corresponding memory allocation to fail.  | 
1643  |  | **  | 
1644  |  | ** The xInit method initializes the memory allocator.  For example,  | 
1645  |  | ** it might allocate any required mutexes or initialize internal data  | 
1646  |  | ** structures.  The xShutdown method is invoked (indirectly) by  | 
1647  |  | ** [sqlite3_shutdown()] and should deallocate any resources acquired  | 
1648  |  | ** by xInit.  The pAppData pointer is used as the only parameter to  | 
1649  |  | ** xInit and xShutdown.  | 
1650  |  | **  | 
1651  |  | ** SQLite holds the [SQLITE_MUTEX_STATIC_MAIN] mutex when it invokes  | 
1652  |  | ** the xInit method, so the xInit method need not be threadsafe.  The  | 
1653  |  | ** xShutdown method is only called from [sqlite3_shutdown()] so it does  | 
1654  |  | ** not need to be threadsafe either.  For all other methods, SQLite  | 
1655  |  | ** holds the [SQLITE_MUTEX_STATIC_MEM] mutex as long as the  | 
1656  |  | ** [SQLITE_CONFIG_MEMSTATUS] configuration option is turned on (which  | 
1657  |  | ** it is by default) and so the methods are automatically serialized.  | 
1658  |  | ** However, if [SQLITE_CONFIG_MEMSTATUS] is disabled, then the other  | 
1659  |  | ** methods must be threadsafe or else make their own arrangements for  | 
1660  |  | ** serialization.  | 
1661  |  | **  | 
1662  |  | ** SQLite will never invoke xInit() more than once without an intervening  | 
1663  |  | ** call to xShutdown().  | 
1664  |  | */  | 
1665  |  | typedef struct sqlite3_mem_methods sqlite3_mem_methods;  | 
1666  |  | struct sqlite3_mem_methods { | 
1667  |  |   void *(*xMalloc)(int);         /* Memory allocation function */  | 
1668  |  |   void (*xFree)(void*);          /* Free a prior allocation */  | 
1669  |  |   void *(*xRealloc)(void*,int);  /* Resize an allocation */  | 
1670  |  |   int (*xSize)(void*);           /* Return the size of an allocation */  | 
1671  |  |   int (*xRoundup)(int);          /* Round up request size to allocation size */  | 
1672  |  |   int (*xInit)(void*);           /* Initialize the memory allocator */  | 
1673  |  |   void (*xShutdown)(void*);      /* Deinitialize the memory allocator */  | 
1674  |  |   void *pAppData;                /* Argument to xInit() and xShutdown() */  | 
1675  |  | };  | 
1676  |  |  | 
1677  |  | /*  | 
1678  |  | ** CAPI3REF: Configuration Options  | 
1679  |  | ** KEYWORDS: {configuration option} | 
1680  |  | **  | 
1681  |  | ** These constants are the available integer configuration options that  | 
1682  |  | ** can be passed as the first argument to the [sqlite3_config()] interface.  | 
1683  |  | **  | 
1684  |  | ** New configuration options may be added in future releases of SQLite.  | 
1685  |  | ** Existing configuration options might be discontinued.  Applications  | 
1686  |  | ** should check the return code from [sqlite3_config()] to make sure that  | 
1687  |  | ** the call worked.  The [sqlite3_config()] interface will return a  | 
1688  |  | ** non-zero [error code] if a discontinued or unsupported configuration option  | 
1689  |  | ** is invoked.  | 
1690  |  | **  | 
1691  |  | ** <dl>  | 
1692  |  | ** [[SQLITE_CONFIG_SINGLETHREAD]] <dt>SQLITE_CONFIG_SINGLETHREAD</dt>  | 
1693  |  | ** <dd>There are no arguments to this option.  ^This option sets the  | 
1694  |  | ** [threading mode] to Single-thread.  In other words, it disables  | 
1695  |  | ** all mutexing and puts SQLite into a mode where it can only be used  | 
1696  |  | ** by a single thread.   ^If SQLite is compiled with  | 
1697  |  | ** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then  | 
1698  |  | ** it is not possible to change the [threading mode] from its default  | 
1699  |  | ** value of Single-thread and so [sqlite3_config()] will return  | 
1700  |  | ** [SQLITE_ERROR] if called with the SQLITE_CONFIG_SINGLETHREAD  | 
1701  |  | ** configuration option.</dd>  | 
1702  |  | **  | 
1703  |  | ** [[SQLITE_CONFIG_MULTITHREAD]] <dt>SQLITE_CONFIG_MULTITHREAD</dt>  | 
1704  |  | ** <dd>There are no arguments to this option.  ^This option sets the  | 
1705  |  | ** [threading mode] to Multi-thread.  In other words, it disables  | 
1706  |  | ** mutexing on [database connection] and [prepared statement] objects.  | 
1707  |  | ** The application is responsible for serializing access to  | 
1708  |  | ** [database connections] and [prepared statements].  But other mutexes  | 
1709  |  | ** are enabled so that SQLite will be safe to use in a multi-threaded  | 
1710  |  | ** environment as long as no two threads attempt to use the same  | 
1711  |  | ** [database connection] at the same time.  ^If SQLite is compiled with  | 
1712  |  | ** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then  | 
1713  |  | ** it is not possible to set the Multi-thread [threading mode] and  | 
1714  |  | ** [sqlite3_config()] will return [SQLITE_ERROR] if called with the  | 
1715  |  | ** SQLITE_CONFIG_MULTITHREAD configuration option.</dd>  | 
1716  |  | **  | 
1717  |  | ** [[SQLITE_CONFIG_SERIALIZED]] <dt>SQLITE_CONFIG_SERIALIZED</dt>  | 
1718  |  | ** <dd>There are no arguments to this option.  ^This option sets the  | 
1719  |  | ** [threading mode] to Serialized. In other words, this option enables  | 
1720  |  | ** all mutexes including the recursive  | 
1721  |  | ** mutexes on [database connection] and [prepared statement] objects.  | 
1722  |  | ** In this mode (which is the default when SQLite is compiled with  | 
1723  |  | ** [SQLITE_THREADSAFE=1]) the SQLite library will itself serialize access  | 
1724  |  | ** to [database connections] and [prepared statements] so that the  | 
1725  |  | ** application is free to use the same [database connection] or the  | 
1726  |  | ** same [prepared statement] in different threads at the same time.  | 
1727  |  | ** ^If SQLite is compiled with  | 
1728  |  | ** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then  | 
1729  |  | ** it is not possible to set the Serialized [threading mode] and  | 
1730  |  | ** [sqlite3_config()] will return [SQLITE_ERROR] if called with the  | 
1731  |  | ** SQLITE_CONFIG_SERIALIZED configuration option.</dd>  | 
1732  |  | **  | 
1733  |  | ** [[SQLITE_CONFIG_MALLOC]] <dt>SQLITE_CONFIG_MALLOC</dt>  | 
1734  |  | ** <dd> ^(The SQLITE_CONFIG_MALLOC option takes a single argument which is  | 
1735  |  | ** a pointer to an instance of the [sqlite3_mem_methods] structure.  | 
1736  |  | ** The argument specifies  | 
1737  |  | ** alternative low-level memory allocation routines to be used in place of  | 
1738  |  | ** the memory allocation routines built into SQLite.)^ ^SQLite makes  | 
1739  |  | ** its own private copy of the content of the [sqlite3_mem_methods] structure  | 
1740  |  | ** before the [sqlite3_config()] call returns.</dd>  | 
1741  |  | **  | 
1742  |  | ** [[SQLITE_CONFIG_GETMALLOC]] <dt>SQLITE_CONFIG_GETMALLOC</dt>  | 
1743  |  | ** <dd> ^(The SQLITE_CONFIG_GETMALLOC option takes a single argument which  | 
1744  |  | ** is a pointer to an instance of the [sqlite3_mem_methods] structure.  | 
1745  |  | ** The [sqlite3_mem_methods]  | 
1746  |  | ** structure is filled with the currently defined memory allocation routines.)^  | 
1747  |  | ** This option can be used to overload the default memory allocation  | 
1748  |  | ** routines with a wrapper that simulations memory allocation failure or  | 
1749  |  | ** tracks memory usage, for example. </dd>  | 
1750  |  | **  | 
1751  |  | ** [[SQLITE_CONFIG_SMALL_MALLOC]] <dt>SQLITE_CONFIG_SMALL_MALLOC</dt>  | 
1752  |  | ** <dd> ^The SQLITE_CONFIG_SMALL_MALLOC option takes single argument of  | 
1753  |  | ** type int, interpreted as a boolean, which if true provides a hint to  | 
1754  |  | ** SQLite that it should avoid large memory allocations if possible.  | 
1755  |  | ** SQLite will run faster if it is free to make large memory allocations,  | 
1756  |  | ** but some application might prefer to run slower in exchange for  | 
1757  |  | ** guarantees about memory fragmentation that are possible if large  | 
1758  |  | ** allocations are avoided.  This hint is normally off.  | 
1759  |  | ** </dd>  | 
1760  |  | **  | 
1761  |  | ** [[SQLITE_CONFIG_MEMSTATUS]] <dt>SQLITE_CONFIG_MEMSTATUS</dt>  | 
1762  |  | ** <dd> ^The SQLITE_CONFIG_MEMSTATUS option takes single argument of type int,  | 
1763  |  | ** interpreted as a boolean, which enables or disables the collection of  | 
1764  |  | ** memory allocation statistics. ^(When memory allocation statistics are  | 
1765  |  | ** disabled, the following SQLite interfaces become non-operational:  | 
1766  |  | **   <ul>  | 
1767  |  | **   <li> [sqlite3_hard_heap_limit64()]  | 
1768  |  | **   <li> [sqlite3_memory_used()]  | 
1769  |  | **   <li> [sqlite3_memory_highwater()]  | 
1770  |  | **   <li> [sqlite3_soft_heap_limit64()]  | 
1771  |  | **   <li> [sqlite3_status64()]  | 
1772  |  | **   </ul>)^  | 
1773  |  | ** ^Memory allocation statistics are enabled by default unless SQLite is  | 
1774  |  | ** compiled with [SQLITE_DEFAULT_MEMSTATUS]=0 in which case memory  | 
1775  |  | ** allocation statistics are disabled by default.  | 
1776  |  | ** </dd>  | 
1777  |  | **  | 
1778  |  | ** [[SQLITE_CONFIG_SCRATCH]] <dt>SQLITE_CONFIG_SCRATCH</dt>  | 
1779  |  | ** <dd> The SQLITE_CONFIG_SCRATCH option is no longer used.  | 
1780  |  | ** </dd>  | 
1781  |  | **  | 
1782  |  | ** [[SQLITE_CONFIG_PAGECACHE]] <dt>SQLITE_CONFIG_PAGECACHE</dt>  | 
1783  |  | ** <dd> ^The SQLITE_CONFIG_PAGECACHE option specifies a memory pool  | 
1784  |  | ** that SQLite can use for the database page cache with the default page  | 
1785  |  | ** cache implementation.  | 
1786  |  | ** This configuration option is a no-op if an application-defined page  | 
1787  |  | ** cache implementation is loaded using the [SQLITE_CONFIG_PCACHE2].  | 
1788  |  | ** ^There are three arguments to SQLITE_CONFIG_PAGECACHE: A pointer to  | 
1789  |  | ** 8-byte aligned memory (pMem), the size of each page cache line (sz),  | 
1790  |  | ** and the number of cache lines (N).  | 
1791  |  | ** The sz argument should be the size of the largest database page  | 
1792  |  | ** (a power of two between 512 and 65536) plus some extra bytes for each  | 
1793  |  | ** page header.  ^The number of extra bytes needed by the page header  | 
1794  |  | ** can be determined using [SQLITE_CONFIG_PCACHE_HDRSZ].  | 
1795  |  | ** ^It is harmless, apart from the wasted memory,  | 
1796  |  | ** for the sz parameter to be larger than necessary.  The pMem  | 
1797  |  | ** argument must be either a NULL pointer or a pointer to an 8-byte  | 
1798  |  | ** aligned block of memory of at least sz*N bytes, otherwise  | 
1799  |  | ** subsequent behavior is undefined.  | 
1800  |  | ** ^When pMem is not NULL, SQLite will strive to use the memory provided  | 
1801  |  | ** to satisfy page cache needs, falling back to [sqlite3_malloc()] if  | 
1802  |  | ** a page cache line is larger than sz bytes or if all of the pMem buffer  | 
1803  |  | ** is exhausted.  | 
1804  |  | ** ^If pMem is NULL and N is non-zero, then each database connection  | 
1805  |  | ** does an initial bulk allocation for page cache memory  | 
1806  |  | ** from [sqlite3_malloc()] sufficient for N cache lines if N is positive or  | 
1807  |  | ** of -1024*N bytes if N is negative, . ^If additional  | 
1808  |  | ** page cache memory is needed beyond what is provided by the initial  | 
1809  |  | ** allocation, then SQLite goes to [sqlite3_malloc()] separately for each  | 
1810  |  | ** additional cache line. </dd>  | 
1811  |  | **  | 
1812  |  | ** [[SQLITE_CONFIG_HEAP]] <dt>SQLITE_CONFIG_HEAP</dt>  | 
1813  |  | ** <dd> ^The SQLITE_CONFIG_HEAP option specifies a static memory buffer  | 
1814  |  | ** that SQLite will use for all of its dynamic memory allocation needs  | 
1815  |  | ** beyond those provided for by [SQLITE_CONFIG_PAGECACHE].  | 
1816  |  | ** ^The SQLITE_CONFIG_HEAP option is only available if SQLite is compiled  | 
1817  |  | ** with either [SQLITE_ENABLE_MEMSYS3] or [SQLITE_ENABLE_MEMSYS5] and returns  | 
1818  |  | ** [SQLITE_ERROR] if invoked otherwise.  | 
1819  |  | ** ^There are three arguments to SQLITE_CONFIG_HEAP:  | 
1820  |  | ** An 8-byte aligned pointer to the memory,  | 
1821  |  | ** the number of bytes in the memory buffer, and the minimum allocation size.  | 
1822  |  | ** ^If the first pointer (the memory pointer) is NULL, then SQLite reverts  | 
1823  |  | ** to using its default memory allocator (the system malloc() implementation),  | 
1824  |  | ** undoing any prior invocation of [SQLITE_CONFIG_MALLOC].  ^If the  | 
1825  |  | ** memory pointer is not NULL then the alternative memory  | 
1826  |  | ** allocator is engaged to handle all of SQLites memory allocation needs.  | 
1827  |  | ** The first pointer (the memory pointer) must be aligned to an 8-byte  | 
1828  |  | ** boundary or subsequent behavior of SQLite will be undefined.  | 
1829  |  | ** The minimum allocation size is capped at 2**12. Reasonable values  | 
1830  |  | ** for the minimum allocation size are 2**5 through 2**8.</dd>  | 
1831  |  | **  | 
1832  |  | ** [[SQLITE_CONFIG_MUTEX]] <dt>SQLITE_CONFIG_MUTEX</dt>  | 
1833  |  | ** <dd> ^(The SQLITE_CONFIG_MUTEX option takes a single argument which is a  | 
1834  |  | ** pointer to an instance of the [sqlite3_mutex_methods] structure.  | 
1835  |  | ** The argument specifies alternative low-level mutex routines to be used  | 
1836  |  | ** in place the mutex routines built into SQLite.)^  ^SQLite makes a copy of  | 
1837  |  | ** the content of the [sqlite3_mutex_methods] structure before the call to  | 
1838  |  | ** [sqlite3_config()] returns. ^If SQLite is compiled with  | 
1839  |  | ** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then  | 
1840  |  | ** the entire mutexing subsystem is omitted from the build and hence calls to  | 
1841  |  | ** [sqlite3_config()] with the SQLITE_CONFIG_MUTEX configuration option will  | 
1842  |  | ** return [SQLITE_ERROR].</dd>  | 
1843  |  | **  | 
1844  |  | ** [[SQLITE_CONFIG_GETMUTEX]] <dt>SQLITE_CONFIG_GETMUTEX</dt>  | 
1845  |  | ** <dd> ^(The SQLITE_CONFIG_GETMUTEX option takes a single argument which  | 
1846  |  | ** is a pointer to an instance of the [sqlite3_mutex_methods] structure.  The  | 
1847  |  | ** [sqlite3_mutex_methods]  | 
1848  |  | ** structure is filled with the currently defined mutex routines.)^  | 
1849  |  | ** This option can be used to overload the default mutex allocation  | 
1850  |  | ** routines with a wrapper used to track mutex usage for performance  | 
1851  |  | ** profiling or testing, for example.   ^If SQLite is compiled with  | 
1852  |  | ** the [SQLITE_THREADSAFE | SQLITE_THREADSAFE=0] compile-time option then  | 
1853  |  | ** the entire mutexing subsystem is omitted from the build and hence calls to  | 
1854  |  | ** [sqlite3_config()] with the SQLITE_CONFIG_GETMUTEX configuration option will  | 
1855  |  | ** return [SQLITE_ERROR].</dd>  | 
1856  |  | **  | 
1857  |  | ** [[SQLITE_CONFIG_LOOKASIDE]] <dt>SQLITE_CONFIG_LOOKASIDE</dt>  | 
1858  |  | ** <dd> ^(The SQLITE_CONFIG_LOOKASIDE option takes two arguments that determine  | 
1859  |  | ** the default size of lookaside memory on each [database connection].  | 
1860  |  | ** The first argument is the  | 
1861  |  | ** size of each lookaside buffer slot and the second is the number of  | 
1862  |  | ** slots allocated to each database connection.)^  ^(SQLITE_CONFIG_LOOKASIDE  | 
1863  |  | ** sets the <i>default</i> lookaside size. The [SQLITE_DBCONFIG_LOOKASIDE]  | 
1864  |  | ** option to [sqlite3_db_config()] can be used to change the lookaside  | 
1865  |  | ** configuration on individual connections.)^ </dd>  | 
1866  |  | **  | 
1867  |  | ** [[SQLITE_CONFIG_PCACHE2]] <dt>SQLITE_CONFIG_PCACHE2</dt>  | 
1868  |  | ** <dd> ^(The SQLITE_CONFIG_PCACHE2 option takes a single argument which is  | 
1869  |  | ** a pointer to an [sqlite3_pcache_methods2] object.  This object specifies  | 
1870  |  | ** the interface to a custom page cache implementation.)^  | 
1871  |  | ** ^SQLite makes a copy of the [sqlite3_pcache_methods2] object.</dd>  | 
1872  |  | **  | 
1873  |  | ** [[SQLITE_CONFIG_GETPCACHE2]] <dt>SQLITE_CONFIG_GETPCACHE2</dt>  | 
1874  |  | ** <dd> ^(The SQLITE_CONFIG_GETPCACHE2 option takes a single argument which  | 
1875  |  | ** is a pointer to an [sqlite3_pcache_methods2] object.  SQLite copies of  | 
1876  |  | ** the current page cache implementation into that object.)^ </dd>  | 
1877  |  | **  | 
1878  |  | ** [[SQLITE_CONFIG_LOG]] <dt>SQLITE_CONFIG_LOG</dt>  | 
1879  |  | ** <dd> The SQLITE_CONFIG_LOG option is used to configure the SQLite  | 
1880  |  | ** global [error log].  | 
1881  |  | ** (^The SQLITE_CONFIG_LOG option takes two arguments: a pointer to a  | 
1882  |  | ** function with a call signature of void(*)(void*,int,const char*),  | 
1883  |  | ** and a pointer to void. ^If the function pointer is not NULL, it is  | 
1884  |  | ** invoked by [sqlite3_log()] to process each logging event.  ^If the  | 
1885  |  | ** function pointer is NULL, the [sqlite3_log()] interface becomes a no-op.  | 
1886  |  | ** ^The void pointer that is the second argument to SQLITE_CONFIG_LOG is  | 
1887  |  | ** passed through as the first parameter to the application-defined logger  | 
1888  |  | ** function whenever that function is invoked.  ^The second parameter to  | 
1889  |  | ** the logger function is a copy of the first parameter to the corresponding  | 
1890  |  | ** [sqlite3_log()] call and is intended to be a [result code] or an  | 
1891  |  | ** [extended result code].  ^The third parameter passed to the logger is  | 
1892  |  | ** log message after formatting via [sqlite3_snprintf()].  | 
1893  |  | ** The SQLite logging interface is not reentrant; the logger function  | 
1894  |  | ** supplied by the application must not invoke any SQLite interface.  | 
1895  |  | ** In a multi-threaded application, the application-defined logger  | 
1896  |  | ** function must be threadsafe. </dd>  | 
1897  |  | **  | 
1898  |  | ** [[SQLITE_CONFIG_URI]] <dt>SQLITE_CONFIG_URI  | 
1899  |  | ** <dd>^(The SQLITE_CONFIG_URI option takes a single argument of type int.  | 
1900  |  | ** If non-zero, then URI handling is globally enabled. If the parameter is zero,  | 
1901  |  | ** then URI handling is globally disabled.)^ ^If URI handling is globally  | 
1902  |  | ** enabled, all filenames passed to [sqlite3_open()], [sqlite3_open_v2()],  | 
1903  |  | ** [sqlite3_open16()] or  | 
1904  |  | ** specified as part of [ATTACH] commands are interpreted as URIs, regardless  | 
1905  |  | ** of whether or not the [SQLITE_OPEN_URI] flag is set when the database  | 
1906  |  | ** connection is opened. ^If it is globally disabled, filenames are  | 
1907  |  | ** only interpreted as URIs if the SQLITE_OPEN_URI flag is set when the  | 
1908  |  | ** database connection is opened. ^(By default, URI handling is globally  | 
1909  |  | ** disabled. The default value may be changed by compiling with the  | 
1910  |  | ** [SQLITE_USE_URI] symbol defined.)^  | 
1911  |  | **  | 
1912  |  | ** [[SQLITE_CONFIG_COVERING_INDEX_SCAN]] <dt>SQLITE_CONFIG_COVERING_INDEX_SCAN  | 
1913  |  | ** <dd>^The SQLITE_CONFIG_COVERING_INDEX_SCAN option takes a single integer  | 
1914  |  | ** argument which is interpreted as a boolean in order to enable or disable  | 
1915  |  | ** the use of covering indices for full table scans in the query optimizer.  | 
1916  |  | ** ^The default setting is determined  | 
1917  |  | ** by the [SQLITE_ALLOW_COVERING_INDEX_SCAN] compile-time option, or is "on"  | 
1918  |  | ** if that compile-time option is omitted.  | 
1919  |  | ** The ability to disable the use of covering indices for full table scans  | 
1920  |  | ** is because some incorrectly coded legacy applications might malfunction  | 
1921  |  | ** when the optimization is enabled.  Providing the ability to  | 
1922  |  | ** disable the optimization allows the older, buggy application code to work  | 
1923  |  | ** without change even with newer versions of SQLite.  | 
1924  |  | **  | 
1925  |  | ** [[SQLITE_CONFIG_PCACHE]] [[SQLITE_CONFIG_GETPCACHE]]  | 
1926  |  | ** <dt>SQLITE_CONFIG_PCACHE and SQLITE_CONFIG_GETPCACHE  | 
1927  |  | ** <dd> These options are obsolete and should not be used by new code.  | 
1928  |  | ** They are retained for backwards compatibility but are now no-ops.  | 
1929  |  | ** </dd>  | 
1930  |  | **  | 
1931  |  | ** [[SQLITE_CONFIG_SQLLOG]]  | 
1932  |  | ** <dt>SQLITE_CONFIG_SQLLOG  | 
1933  |  | ** <dd>This option is only available if sqlite is compiled with the  | 
1934  |  | ** [SQLITE_ENABLE_SQLLOG] pre-processor macro defined. The first argument should  | 
1935  |  | ** be a pointer to a function of type void(*)(void*,sqlite3*,const char*, int).  | 
1936  |  | ** The second should be of type (void*). The callback is invoked by the library  | 
1937  |  | ** in three separate circumstances, identified by the value passed as the  | 
1938  |  | ** fourth parameter. If the fourth parameter is 0, then the database connection  | 
1939  |  | ** passed as the second argument has just been opened. The third argument  | 
1940  |  | ** points to a buffer containing the name of the main database file. If the  | 
1941  |  | ** fourth parameter is 1, then the SQL statement that the third parameter  | 
1942  |  | ** points to has just been executed. Or, if the fourth parameter is 2, then  | 
1943  |  | ** the connection being passed as the second parameter is being closed. The  | 
1944  |  | ** third parameter is passed NULL In this case.  An example of using this  | 
1945  |  | ** configuration option can be seen in the "test_sqllog.c" source file in  | 
1946  |  | ** the canonical SQLite source tree.</dd>  | 
1947  |  | **  | 
1948  |  | ** [[SQLITE_CONFIG_MMAP_SIZE]]  | 
1949  |  | ** <dt>SQLITE_CONFIG_MMAP_SIZE  | 
1950  |  | ** <dd>^SQLITE_CONFIG_MMAP_SIZE takes two 64-bit integer (sqlite3_int64) values  | 
1951  |  | ** that are the default mmap size limit (the default setting for  | 
1952  |  | ** [PRAGMA mmap_size]) and the maximum allowed mmap size limit.  | 
1953  |  | ** ^The default setting can be overridden by each database connection using  | 
1954  |  | ** either the [PRAGMA mmap_size] command, or by using the  | 
1955  |  | ** [SQLITE_FCNTL_MMAP_SIZE] file control.  ^(The maximum allowed mmap size  | 
1956  |  | ** will be silently truncated if necessary so that it does not exceed the  | 
1957  |  | ** compile-time maximum mmap size set by the  | 
1958  |  | ** [SQLITE_MAX_MMAP_SIZE] compile-time option.)^  | 
1959  |  | ** ^If either argument to this option is negative, then that argument is  | 
1960  |  | ** changed to its compile-time default.  | 
1961  |  | **  | 
1962  |  | ** [[SQLITE_CONFIG_WIN32_HEAPSIZE]]  | 
1963  |  | ** <dt>SQLITE_CONFIG_WIN32_HEAPSIZE  | 
1964  |  | ** <dd>^The SQLITE_CONFIG_WIN32_HEAPSIZE option is only available if SQLite is  | 
1965  |  | ** compiled for Windows with the [SQLITE_WIN32_MALLOC] pre-processor macro  | 
1966  |  | ** defined. ^SQLITE_CONFIG_WIN32_HEAPSIZE takes a 32-bit unsigned integer value  | 
1967  |  | ** that specifies the maximum size of the created heap.  | 
1968  |  | **  | 
1969  |  | ** [[SQLITE_CONFIG_PCACHE_HDRSZ]]  | 
1970  |  | ** <dt>SQLITE_CONFIG_PCACHE_HDRSZ  | 
1971  |  | ** <dd>^The SQLITE_CONFIG_PCACHE_HDRSZ option takes a single parameter which  | 
1972  |  | ** is a pointer to an integer and writes into that integer the number of extra  | 
1973  |  | ** bytes per page required for each page in [SQLITE_CONFIG_PAGECACHE].  | 
1974  |  | ** The amount of extra space required can change depending on the compiler,  | 
1975  |  | ** target platform, and SQLite version.  | 
1976  |  | **  | 
1977  |  | ** [[SQLITE_CONFIG_PMASZ]]  | 
1978  |  | ** <dt>SQLITE_CONFIG_PMASZ  | 
1979  |  | ** <dd>^The SQLITE_CONFIG_PMASZ option takes a single parameter which  | 
1980  |  | ** is an unsigned integer and sets the "Minimum PMA Size" for the multithreaded  | 
1981  |  | ** sorter to that integer.  The default minimum PMA Size is set by the  | 
1982  |  | ** [SQLITE_SORTER_PMASZ] compile-time option.  New threads are launched  | 
1983  |  | ** to help with sort operations when multithreaded sorting  | 
1984  |  | ** is enabled (using the [PRAGMA threads] command) and the amount of content  | 
1985  |  | ** to be sorted exceeds the page size times the minimum of the  | 
1986  |  | ** [PRAGMA cache_size] setting and this value.  | 
1987  |  | **  | 
1988  |  | ** [[SQLITE_CONFIG_STMTJRNL_SPILL]]  | 
1989  |  | ** <dt>SQLITE_CONFIG_STMTJRNL_SPILL  | 
1990  |  | ** <dd>^The SQLITE_CONFIG_STMTJRNL_SPILL option takes a single parameter which  | 
1991  |  | ** becomes the [statement journal] spill-to-disk threshold.  | 
1992  |  | ** [Statement journals] are held in memory until their size (in bytes)  | 
1993  |  | ** exceeds this threshold, at which point they are written to disk.  | 
1994  |  | ** Or if the threshold is -1, statement journals are always held  | 
1995  |  | ** exclusively in memory.  | 
1996  |  | ** Since many statement journals never become large, setting the spill  | 
1997  |  | ** threshold to a value such as 64KiB can greatly reduce the amount of  | 
1998  |  | ** I/O required to support statement rollback.  | 
1999  |  | ** The default value for this setting is controlled by the  | 
2000  |  | ** [SQLITE_STMTJRNL_SPILL] compile-time option.  | 
2001  |  | **  | 
2002  |  | ** [[SQLITE_CONFIG_SORTERREF_SIZE]]  | 
2003  |  | ** <dt>SQLITE_CONFIG_SORTERREF_SIZE  | 
2004  |  | ** <dd>The SQLITE_CONFIG_SORTERREF_SIZE option accepts a single parameter  | 
2005  |  | ** of type (int) - the new value of the sorter-reference size threshold.  | 
2006  |  | ** Usually, when SQLite uses an external sort to order records according  | 
2007  |  | ** to an ORDER BY clause, all fields required by the caller are present in the  | 
2008  |  | ** sorted records. However, if SQLite determines based on the declared type  | 
2009  |  | ** of a table column that its values are likely to be very large - larger  | 
2010  |  | ** than the configured sorter-reference size threshold - then a reference  | 
2011  |  | ** is stored in each sorted record and the required column values loaded  | 
2012  |  | ** from the database as records are returned in sorted order. The default  | 
2013  |  | ** value for this option is to never use this optimization. Specifying a  | 
2014  |  | ** negative value for this option restores the default behaviour.  | 
2015  |  | ** This option is only available if SQLite is compiled with the  | 
2016  |  | ** [SQLITE_ENABLE_SORTER_REFERENCES] compile-time option.  | 
2017  |  | **  | 
2018  |  | ** [[SQLITE_CONFIG_MEMDB_MAXSIZE]]  | 
2019  |  | ** <dt>SQLITE_CONFIG_MEMDB_MAXSIZE  | 
2020  |  | ** <dd>The SQLITE_CONFIG_MEMDB_MAXSIZE option accepts a single parameter  | 
2021  |  | ** [sqlite3_int64] parameter which is the default maximum size for an in-memory  | 
2022  |  | ** database created using [sqlite3_deserialize()].  This default maximum  | 
2023  |  | ** size can be adjusted up or down for individual databases using the  | 
2024  |  | ** [SQLITE_FCNTL_SIZE_LIMIT] [sqlite3_file_control|file-control].  If this  | 
2025  |  | ** configuration setting is never used, then the default maximum is determined  | 
2026  |  | ** by the [SQLITE_MEMDB_DEFAULT_MAXSIZE] compile-time option.  If that  | 
2027  |  | ** compile-time option is not set, then the default maximum is 1073741824.  | 
2028  |  | ** </dl>  | 
2029  |  | */  | 
2030  |  | #define SQLITE_CONFIG_SINGLETHREAD  1  /* nil */  | 
2031  |  | #define SQLITE_CONFIG_MULTITHREAD   2  /* nil */  | 
2032  |  | #define SQLITE_CONFIG_SERIALIZED    3  /* nil */  | 
2033  |  | #define SQLITE_CONFIG_MALLOC        4  /* sqlite3_mem_methods* */  | 
2034  |  | #define SQLITE_CONFIG_GETMALLOC     5  /* sqlite3_mem_methods* */  | 
2035  |  | #define SQLITE_CONFIG_SCRATCH       6  /* No longer used */  | 
2036  |  | #define SQLITE_CONFIG_PAGECACHE     7  /* void*, int sz, int N */  | 
2037  |  | #define SQLITE_CONFIG_HEAP          8  /* void*, int nByte, int min */  | 
2038  |  | #define SQLITE_CONFIG_MEMSTATUS     9  /* boolean */  | 
2039  |  | #define SQLITE_CONFIG_MUTEX        10  /* sqlite3_mutex_methods* */  | 
2040  |  | #define SQLITE_CONFIG_GETMUTEX     11  /* sqlite3_mutex_methods* */  | 
2041  |  | /* previously SQLITE_CONFIG_CHUNKALLOC 12 which is now unused. */  | 
2042  |  | #define SQLITE_CONFIG_LOOKASIDE    13  /* int int */  | 
2043  |  | #define SQLITE_CONFIG_PCACHE       14  /* no-op */  | 
2044  |  | #define SQLITE_CONFIG_GETPCACHE    15  /* no-op */  | 
2045  |  | #define SQLITE_CONFIG_LOG          16  /* xFunc, void* */  | 
2046  |  | #define SQLITE_CONFIG_URI          17  /* int */  | 
2047  |  | #define SQLITE_CONFIG_PCACHE2      18  /* sqlite3_pcache_methods2* */  | 
2048  |  | #define SQLITE_CONFIG_GETPCACHE2   19  /* sqlite3_pcache_methods2* */  | 
2049  |  | #define SQLITE_CONFIG_COVERING_INDEX_SCAN 20  /* int */  | 
2050  |  | #define SQLITE_CONFIG_SQLLOG       21  /* xSqllog, void* */  | 
2051  |  | #define SQLITE_CONFIG_MMAP_SIZE    22  /* sqlite3_int64, sqlite3_int64 */  | 
2052  |  | #define SQLITE_CONFIG_WIN32_HEAPSIZE      23  /* int nByte */  | 
2053  |  | #define SQLITE_CONFIG_PCACHE_HDRSZ        24  /* int *psz */  | 
2054  |  | #define SQLITE_CONFIG_PMASZ               25  /* unsigned int szPma */  | 
2055  |  | #define SQLITE_CONFIG_STMTJRNL_SPILL      26  /* int nByte */  | 
2056  |  | #define SQLITE_CONFIG_SMALL_MALLOC        27  /* boolean */  | 
2057  |  | #define SQLITE_CONFIG_SORTERREF_SIZE      28  /* int nByte */  | 
2058  |  | #define SQLITE_CONFIG_MEMDB_MAXSIZE       29  /* sqlite3_int64 */  | 
2059  |  |  | 
2060  |  | /*  | 
2061  |  | ** CAPI3REF: Database Connection Configuration Options  | 
2062  |  | **  | 
2063  |  | ** These constants are the available integer configuration options that  | 
2064  |  | ** can be passed as the second argument to the [sqlite3_db_config()] interface.  | 
2065  |  | **  | 
2066  |  | ** New configuration options may be added in future releases of SQLite.  | 
2067  |  | ** Existing configuration options might be discontinued.  Applications  | 
2068  |  | ** should check the return code from [sqlite3_db_config()] to make sure that  | 
2069  |  | ** the call worked.  ^The [sqlite3_db_config()] interface will return a  | 
2070  |  | ** non-zero [error code] if a discontinued or unsupported configuration option  | 
2071  |  | ** is invoked.  | 
2072  |  | **  | 
2073  |  | ** <dl>  | 
2074  |  | ** [[SQLITE_DBCONFIG_LOOKASIDE]]  | 
2075  |  | ** <dt>SQLITE_DBCONFIG_LOOKASIDE</dt>  | 
2076  |  | ** <dd> ^This option takes three additional arguments that determine the  | 
2077  |  | ** [lookaside memory allocator] configuration for the [database connection].  | 
2078  |  | ** ^The first argument (the third parameter to [sqlite3_db_config()] is a  | 
2079  |  | ** pointer to a memory buffer to use for lookaside memory.  | 
2080  |  | ** ^The first argument after the SQLITE_DBCONFIG_LOOKASIDE verb  | 
2081  |  | ** may be NULL in which case SQLite will allocate the  | 
2082  |  | ** lookaside buffer itself using [sqlite3_malloc()]. ^The second argument is the  | 
2083  |  | ** size of each lookaside buffer slot.  ^The third argument is the number of  | 
2084  |  | ** slots.  The size of the buffer in the first argument must be greater than  | 
2085  |  | ** or equal to the product of the second and third arguments.  The buffer  | 
2086  |  | ** must be aligned to an 8-byte boundary.  ^If the second argument to  | 
2087  |  | ** SQLITE_DBCONFIG_LOOKASIDE is not a multiple of 8, it is internally  | 
2088  |  | ** rounded down to the next smaller multiple of 8.  ^(The lookaside memory  | 
2089  |  | ** configuration for a database connection can only be changed when that  | 
2090  |  | ** connection is not currently using lookaside memory, or in other words  | 
2091  |  | ** when the "current value" returned by  | 
2092  |  | ** [sqlite3_db_status](D,[SQLITE_CONFIG_LOOKASIDE],...) is zero.  | 
2093  |  | ** Any attempt to change the lookaside memory configuration when lookaside  | 
2094  |  | ** memory is in use leaves the configuration unchanged and returns  | 
2095  |  | ** [SQLITE_BUSY].)^</dd>  | 
2096  |  | **  | 
2097  |  | ** [[SQLITE_DBCONFIG_ENABLE_FKEY]]  | 
2098  |  | ** <dt>SQLITE_DBCONFIG_ENABLE_FKEY</dt>  | 
2099  |  | ** <dd> ^This option is used to enable or disable the enforcement of  | 
2100  |  | ** [foreign key constraints].  There should be two additional arguments.  | 
2101  |  | ** The first argument is an integer which is 0 to disable FK enforcement,  | 
2102  |  | ** positive to enable FK enforcement or negative to leave FK enforcement  | 
2103  |  | ** unchanged.  The second parameter is a pointer to an integer into which  | 
2104  |  | ** is written 0 or 1 to indicate whether FK enforcement is off or on  | 
2105  |  | ** following this call.  The second parameter may be a NULL pointer, in  | 
2106  |  | ** which case the FK enforcement setting is not reported back. </dd>  | 
2107  |  | **  | 
2108  |  | ** [[SQLITE_DBCONFIG_ENABLE_TRIGGER]]  | 
2109  |  | ** <dt>SQLITE_DBCONFIG_ENABLE_TRIGGER</dt>  | 
2110  |  | ** <dd> ^This option is used to enable or disable [CREATE TRIGGER | triggers].  | 
2111  |  | ** There should be two additional arguments.  | 
2112  |  | ** The first argument is an integer which is 0 to disable triggers,  | 
2113  |  | ** positive to enable triggers or negative to leave the setting unchanged.  | 
2114  |  | ** The second parameter is a pointer to an integer into which  | 
2115  |  | ** is written 0 or 1 to indicate whether triggers are disabled or enabled  | 
2116  |  | ** following this call.  The second parameter may be a NULL pointer, in  | 
2117  |  | ** which case the trigger setting is not reported back. </dd>  | 
2118  |  | **  | 
2119  |  | ** [[SQLITE_DBCONFIG_ENABLE_VIEW]]  | 
2120  |  | ** <dt>SQLITE_DBCONFIG_ENABLE_VIEW</dt>  | 
2121  |  | ** <dd> ^This option is used to enable or disable [CREATE VIEW | views].  | 
2122  |  | ** There should be two additional arguments.  | 
2123  |  | ** The first argument is an integer which is 0 to disable views,  | 
2124  |  | ** positive to enable views or negative to leave the setting unchanged.  | 
2125  |  | ** The second parameter is a pointer to an integer into which  | 
2126  |  | ** is written 0 or 1 to indicate whether views are disabled or enabled  | 
2127  |  | ** following this call.  The second parameter may be a NULL pointer, in  | 
2128  |  | ** which case the view setting is not reported back. </dd>  | 
2129  |  | **  | 
2130  |  | ** [[SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER]]  | 
2131  |  | ** <dt>SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER</dt>  | 
2132  |  | ** <dd> ^This option is used to enable or disable the  | 
2133  |  | ** [fts3_tokenizer()] function which is part of the  | 
2134  |  | ** [FTS3] full-text search engine extension.  | 
2135  |  | ** There should be two additional arguments.  | 
2136  |  | ** The first argument is an integer which is 0 to disable fts3_tokenizer() or  | 
2137  |  | ** positive to enable fts3_tokenizer() or negative to leave the setting  | 
2138  |  | ** unchanged.  | 
2139  |  | ** The second parameter is a pointer to an integer into which  | 
2140  |  | ** is written 0 or 1 to indicate whether fts3_tokenizer is disabled or enabled  | 
2141  |  | ** following this call.  The second parameter may be a NULL pointer, in  | 
2142  |  | ** which case the new setting is not reported back. </dd>  | 
2143  |  | **  | 
2144  |  | ** [[SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION]]  | 
2145  |  | ** <dt>SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION</dt>  | 
2146  |  | ** <dd> ^This option is used to enable or disable the [sqlite3_load_extension()]  | 
2147  |  | ** interface independently of the [load_extension()] SQL function.  | 
2148  |  | ** The [sqlite3_enable_load_extension()] API enables or disables both the  | 
2149  |  | ** C-API [sqlite3_load_extension()] and the SQL function [load_extension()].  | 
2150  |  | ** There should be two additional arguments.  | 
2151  |  | ** When the first argument to this interface is 1, then only the C-API is  | 
2152  |  | ** enabled and the SQL function remains disabled.  If the first argument to  | 
2153  |  | ** this interface is 0, then both the C-API and the SQL function are disabled.  | 
2154  |  | ** If the first argument is -1, then no changes are made to state of either the  | 
2155  |  | ** C-API or the SQL function.  | 
2156  |  | ** The second parameter is a pointer to an integer into which  | 
2157  |  | ** is written 0 or 1 to indicate whether [sqlite3_load_extension()] interface  | 
2158  |  | ** is disabled or enabled following this call.  The second parameter may  | 
2159  |  | ** be a NULL pointer, in which case the new setting is not reported back.  | 
2160  |  | ** </dd>  | 
2161  |  | **  | 
2162  |  | ** [[SQLITE_DBCONFIG_MAINDBNAME]] <dt>SQLITE_DBCONFIG_MAINDBNAME</dt>  | 
2163  |  | ** <dd> ^This option is used to change the name of the "main" database  | 
2164  |  | ** schema.  ^The sole argument is a pointer to a constant UTF8 string  | 
2165  |  | ** which will become the new schema name in place of "main".  ^SQLite  | 
2166  |  | ** does not make a copy of the new main schema name string, so the application  | 
2167  |  | ** must ensure that the argument passed into this DBCONFIG option is unchanged  | 
2168  |  | ** until after the database connection closes.  | 
2169  |  | ** </dd>  | 
2170  |  | **  | 
2171  |  | ** [[SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE]]  | 
2172  |  | ** <dt>SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE</dt>  | 
2173  |  | ** <dd> Usually, when a database in wal mode is closed or detached from a  | 
2174  |  | ** database handle, SQLite checks if this will mean that there are now no  | 
2175  |  | ** connections at all to the database. If so, it performs a checkpoint  | 
2176  |  | ** operation before closing the connection. This option may be used to  | 
2177  |  | ** override this behaviour. The first parameter passed to this operation  | 
2178  |  | ** is an integer - positive to disable checkpoints-on-close, or zero (the  | 
2179  |  | ** default) to enable them, and negative to leave the setting unchanged.  | 
2180  |  | ** The second parameter is a pointer to an integer  | 
2181  |  | ** into which is written 0 or 1 to indicate whether checkpoints-on-close  | 
2182  |  | ** have been disabled - 0 if they are not disabled, 1 if they are.  | 
2183  |  | ** </dd>  | 
2184  |  | **  | 
2185  |  | ** [[SQLITE_DBCONFIG_ENABLE_QPSG]] <dt>SQLITE_DBCONFIG_ENABLE_QPSG</dt>  | 
2186  |  | ** <dd>^(The SQLITE_DBCONFIG_ENABLE_QPSG option activates or deactivates  | 
2187  |  | ** the [query planner stability guarantee] (QPSG).  When the QPSG is active,  | 
2188  |  | ** a single SQL query statement will always use the same algorithm regardless  | 
2189  |  | ** of values of [bound parameters].)^ The QPSG disables some query optimizations  | 
2190  |  | ** that look at the values of bound parameters, which can make some queries  | 
2191  |  | ** slower.  But the QPSG has the advantage of more predictable behavior.  With  | 
2192  |  | ** the QPSG active, SQLite will always use the same query plan in the field as  | 
2193  |  | ** was used during testing in the lab.  | 
2194  |  | ** The first argument to this setting is an integer which is 0 to disable  | 
2195  |  | ** the QPSG, positive to enable QPSG, or negative to leave the setting  | 
2196  |  | ** unchanged. The second parameter is a pointer to an integer into which  | 
2197  |  | ** is written 0 or 1 to indicate whether the QPSG is disabled or enabled  | 
2198  |  | ** following this call.  | 
2199  |  | ** </dd>  | 
2200  |  | **  | 
2201  |  | ** [[SQLITE_DBCONFIG_TRIGGER_EQP]] <dt>SQLITE_DBCONFIG_TRIGGER_EQP</dt>  | 
2202  |  | ** <dd> By default, the output of EXPLAIN QUERY PLAN commands does not  | 
2203  |  | ** include output for any operations performed by trigger programs. This  | 
2204  |  | ** option is used to set or clear (the default) a flag that governs this  | 
2205  |  | ** behavior. The first parameter passed to this operation is an integer -  | 
2206  |  | ** positive to enable output for trigger programs, or zero to disable it,  | 
2207  |  | ** or negative to leave the setting unchanged.  | 
2208  |  | ** The second parameter is a pointer to an integer into which is written  | 
2209  |  | ** 0 or 1 to indicate whether output-for-triggers has been disabled - 0 if  | 
2210  |  | ** it is not disabled, 1 if it is.  | 
2211  |  | ** </dd>  | 
2212  |  | **  | 
2213  |  | ** [[SQLITE_DBCONFIG_RESET_DATABASE]] <dt>SQLITE_DBCONFIG_RESET_DATABASE</dt>  | 
2214  |  | ** <dd> Set the SQLITE_DBCONFIG_RESET_DATABASE flag and then run  | 
2215  |  | ** [VACUUM] in order to reset a database back to an empty database  | 
2216  |  | ** with no schema and no content. The following process works even for  | 
2217  |  | ** a badly corrupted database file:  | 
2218  |  | ** <ol>  | 
2219  |  | ** <li> If the database connection is newly opened, make sure it has read the  | 
2220  |  | **      database schema by preparing then discarding some query against the  | 
2221  |  | **      database, or calling sqlite3_table_column_metadata(), ignoring any  | 
2222  |  | **      errors.  This step is only necessary if the application desires to keep  | 
2223  |  | **      the database in WAL mode after the reset if it was in WAL mode before  | 
2224  |  | **      the reset.  | 
2225  |  | ** <li> sqlite3_db_config(db, SQLITE_DBCONFIG_RESET_DATABASE, 1, 0);  | 
2226  |  | ** <li> [sqlite3_exec](db, "[VACUUM]", 0, 0, 0);  | 
2227  |  | ** <li> sqlite3_db_config(db, SQLITE_DBCONFIG_RESET_DATABASE, 0, 0);  | 
2228  |  | ** </ol>  | 
2229  |  | ** Because resetting a database is destructive and irreversible, the  | 
2230  |  | ** process requires the use of this obscure API and multiple steps to help  | 
2231  |  | ** ensure that it does not happen by accident.  | 
2232  |  | **  | 
2233  |  | ** [[SQLITE_DBCONFIG_DEFENSIVE]] <dt>SQLITE_DBCONFIG_DEFENSIVE</dt>  | 
2234  |  | ** <dd>The SQLITE_DBCONFIG_DEFENSIVE option activates or deactivates the  | 
2235  |  | ** "defensive" flag for a database connection.  When the defensive  | 
2236  |  | ** flag is enabled, language features that allow ordinary SQL to  | 
2237  |  | ** deliberately corrupt the database file are disabled.  The disabled  | 
2238  |  | ** features include but are not limited to the following:  | 
2239  |  | ** <ul>  | 
2240  |  | ** <li> The [PRAGMA writable_schema=ON] statement.  | 
2241  |  | ** <li> The [PRAGMA journal_mode=OFF] statement.  | 
2242  |  | ** <li> Writes to the [sqlite_dbpage] virtual table.  | 
2243  |  | ** <li> Direct writes to [shadow tables].  | 
2244  |  | ** </ul>  | 
2245  |  | ** </dd>  | 
2246  |  | **  | 
2247  |  | ** [[SQLITE_DBCONFIG_WRITABLE_SCHEMA]] <dt>SQLITE_DBCONFIG_WRITABLE_SCHEMA</dt>  | 
2248  |  | ** <dd>The SQLITE_DBCONFIG_WRITABLE_SCHEMA option activates or deactivates the  | 
2249  |  | ** "writable_schema" flag. This has the same effect and is logically equivalent  | 
2250  |  | ** to setting [PRAGMA writable_schema=ON] or [PRAGMA writable_schema=OFF].  | 
2251  |  | ** The first argument to this setting is an integer which is 0 to disable  | 
2252  |  | ** the writable_schema, positive to enable writable_schema, or negative to  | 
2253  |  | ** leave the setting unchanged. The second parameter is a pointer to an  | 
2254  |  | ** integer into which is written 0 or 1 to indicate whether the writable_schema  | 
2255  |  | ** is enabled or disabled following this call.  | 
2256  |  | ** </dd>  | 
2257  |  | **  | 
2258  |  | ** [[SQLITE_DBCONFIG_LEGACY_ALTER_TABLE]]  | 
2259  |  | ** <dt>SQLITE_DBCONFIG_LEGACY_ALTER_TABLE</dt>  | 
2260  |  | ** <dd>The SQLITE_DBCONFIG_LEGACY_ALTER_TABLE option activates or deactivates  | 
2261  |  | ** the legacy behavior of the [ALTER TABLE RENAME] command such it  | 
2262  |  | ** behaves as it did prior to [version 3.24.0] (2018-06-04).  See the  | 
2263  |  | ** "Compatibility Notice" on the [ALTER TABLE RENAME documentation] for  | 
2264  |  | ** additional information. This feature can also be turned on and off  | 
2265  |  | ** using the [PRAGMA legacy_alter_table] statement.  | 
2266  |  | ** </dd>  | 
2267  |  | **  | 
2268  |  | ** [[SQLITE_DBCONFIG_DQS_DML]]  | 
2269  |  | ** <dt>SQLITE_DBCONFIG_DQS_DML</td>  | 
2270  |  | ** <dd>The SQLITE_DBCONFIG_DQS_DML option activates or deactivates  | 
2271  |  | ** the legacy [double-quoted string literal] misfeature for DML statements  | 
2272  |  | ** only, that is DELETE, INSERT, SELECT, and UPDATE statements. The  | 
2273  |  | ** default value of this setting is determined by the [-DSQLITE_DQS]  | 
2274  |  | ** compile-time option.  | 
2275  |  | ** </dd>  | 
2276  |  | **  | 
2277  |  | ** [[SQLITE_DBCONFIG_DQS_DDL]]  | 
2278  |  | ** <dt>SQLITE_DBCONFIG_DQS_DDL</td>  | 
2279  |  | ** <dd>The SQLITE_DBCONFIG_DQS option activates or deactivates  | 
2280  |  | ** the legacy [double-quoted string literal] misfeature for DDL statements,  | 
2281  |  | ** such as CREATE TABLE and CREATE INDEX. The  | 
2282  |  | ** default value of this setting is determined by the [-DSQLITE_DQS]  | 
2283  |  | ** compile-time option.  | 
2284  |  | ** </dd>  | 
2285  |  | **  | 
2286  |  | ** [[SQLITE_DBCONFIG_TRUSTED_SCHEMA]]  | 
2287  |  | ** <dt>SQLITE_DBCONFIG_TRUSTED_SCHEMA</td>  | 
2288  |  | ** <dd>The SQLITE_DBCONFIG_TRUSTED_SCHEMA option tells SQLite to  | 
2289  |  | ** assume that database schemas are untainted by malicious content.  | 
2290  |  | ** When the SQLITE_DBCONFIG_TRUSTED_SCHEMA option is disabled, SQLite  | 
2291  |  | ** takes additional defensive steps to protect the application from harm  | 
2292  |  | ** including:  | 
2293  |  | ** <ul>  | 
2294  |  | ** <li> Prohibit the use of SQL functions inside triggers, views,  | 
2295  |  | ** CHECK constraints, DEFAULT clauses, expression indexes,  | 
2296  |  | ** partial indexes, or generated columns  | 
2297  |  | ** unless those functions are tagged with [SQLITE_INNOCUOUS].  | 
2298  |  | ** <li> Prohibit the use of virtual tables inside of triggers or views  | 
2299  |  | ** unless those virtual tables are tagged with [SQLITE_VTAB_INNOCUOUS].  | 
2300  |  | ** </ul>  | 
2301  |  | ** This setting defaults to "on" for legacy compatibility, however  | 
2302  |  | ** all applications are advised to turn it off if possible. This setting  | 
2303  |  | ** can also be controlled using the [PRAGMA trusted_schema] statement.  | 
2304  |  | ** </dd>  | 
2305  |  | **  | 
2306  |  | ** [[SQLITE_DBCONFIG_LEGACY_FILE_FORMAT]]  | 
2307  |  | ** <dt>SQLITE_DBCONFIG_LEGACY_FILE_FORMAT</td>  | 
2308  |  | ** <dd>The SQLITE_DBCONFIG_LEGACY_FILE_FORMAT option activates or deactivates  | 
2309  |  | ** the legacy file format flag.  When activated, this flag causes all newly  | 
2310  |  | ** created database file to have a schema format version number (the 4-byte  | 
2311  |  | ** integer found at offset 44 into the database header) of 1.  This in turn  | 
2312  |  | ** means that the resulting database file will be readable and writable by  | 
2313  |  | ** any SQLite version back to 3.0.0 ([dateof:3.0.0]).  Without this setting,  | 
2314  |  | ** newly created databases are generally not understandable by SQLite versions  | 
2315  |  | ** prior to 3.3.0 ([dateof:3.3.0]).  As these words are written, there  | 
2316  |  | ** is now scarcely any need to generated database files that are compatible  | 
2317  |  | ** all the way back to version 3.0.0, and so this setting is of little  | 
2318  |  | ** practical use, but is provided so that SQLite can continue to claim the  | 
2319  |  | ** ability to generate new database files that are compatible with  version  | 
2320  |  | ** 3.0.0.  | 
2321  |  | ** <p>Note that when the SQLITE_DBCONFIG_LEGACY_FILE_FORMAT setting is on,  | 
2322  |  | ** the [VACUUM] command will fail with an obscure error when attempting to  | 
2323  |  | ** process a table with generated columns and a descending index.  This is  | 
2324  |  | ** not considered a bug since SQLite versions 3.3.0 and earlier do not support  | 
2325  |  | ** either generated columns or decending indexes.  | 
2326  |  | ** </dd>  | 
2327  |  | ** </dl>  | 
2328  |  | */  | 
2329  |  | #define SQLITE_DBCONFIG_MAINDBNAME            1000 /* const char* */  | 
2330  |  | #define SQLITE_DBCONFIG_LOOKASIDE             1001 /* void* int int */  | 
2331  | 20.2k  | #define SQLITE_DBCONFIG_ENABLE_FKEY           1002 /* int int* */  | 
2332  |  | #define SQLITE_DBCONFIG_ENABLE_TRIGGER        1003 /* int int* */  | 
2333  |  | #define SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER 1004 /* int int* */  | 
2334  |  | #define SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION 1005 /* int int* */  | 
2335  |  | #define SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE      1006 /* int int* */  | 
2336  |  | #define SQLITE_DBCONFIG_ENABLE_QPSG           1007 /* int int* */  | 
2337  |  | #define SQLITE_DBCONFIG_TRIGGER_EQP           1008 /* int int* */  | 
2338  |  | #define SQLITE_DBCONFIG_RESET_DATABASE        1009 /* int int* */  | 
2339  |  | #define SQLITE_DBCONFIG_DEFENSIVE             1010 /* int int* */  | 
2340  |  | #define SQLITE_DBCONFIG_WRITABLE_SCHEMA       1011 /* int int* */  | 
2341  |  | #define SQLITE_DBCONFIG_LEGACY_ALTER_TABLE    1012 /* int int* */  | 
2342  |  | #define SQLITE_DBCONFIG_DQS_DML               1013 /* int int* */  | 
2343  |  | #define SQLITE_DBCONFIG_DQS_DDL               1014 /* int int* */  | 
2344  |  | #define SQLITE_DBCONFIG_ENABLE_VIEW           1015 /* int int* */  | 
2345  |  | #define SQLITE_DBCONFIG_LEGACY_FILE_FORMAT    1016 /* int int* */  | 
2346  |  | #define SQLITE_DBCONFIG_TRUSTED_SCHEMA        1017 /* int int* */  | 
2347  |  | #define SQLITE_DBCONFIG_MAX                   1017 /* Largest DBCONFIG */  | 
2348  |  |  | 
2349  |  | /*  | 
2350  |  | ** CAPI3REF: Enable Or Disable Extended Result Codes  | 
2351  |  | ** METHOD: sqlite3  | 
2352  |  | **  | 
2353  |  | ** ^The sqlite3_extended_result_codes() routine enables or disables the  | 
2354  |  | ** [extended result codes] feature of SQLite. ^The extended result  | 
2355  |  | ** codes are disabled by default for historical compatibility.  | 
2356  |  | */  | 
2357  |  | SQLITE_API int sqlite3_extended_result_codes(sqlite3*, int onoff);  | 
2358  |  |  | 
2359  |  | /*  | 
2360  |  | ** CAPI3REF: Last Insert Rowid  | 
2361  |  | ** METHOD: sqlite3  | 
2362  |  | **  | 
2363  |  | ** ^Each entry in most SQLite tables (except for [WITHOUT ROWID] tables)  | 
2364  |  | ** has a unique 64-bit signed  | 
2365  |  | ** integer key called the [ROWID | "rowid"]. ^The rowid is always available  | 
2366  |  | ** as an undeclared column named ROWID, OID, or _ROWID_ as long as those  | 
2367  |  | ** names are not also used by explicitly declared columns. ^If  | 
2368  |  | ** the table has a column of type [INTEGER PRIMARY KEY] then that column  | 
2369  |  | ** is another alias for the rowid.  | 
2370  |  | **  | 
2371  |  | ** ^The sqlite3_last_insert_rowid(D) interface usually returns the [rowid] of  | 
2372  |  | ** the most recent successful [INSERT] into a rowid table or [virtual table]  | 
2373  |  | ** on database connection D. ^Inserts into [WITHOUT ROWID] tables are not  | 
2374  |  | ** recorded. ^If no successful [INSERT]s into rowid tables have ever occurred  | 
2375  |  | ** on the database connection D, then sqlite3_last_insert_rowid(D) returns  | 
2376  |  | ** zero.  | 
2377  |  | **  | 
2378  |  | ** As well as being set automatically as rows are inserted into database  | 
2379  |  | ** tables, the value returned by this function may be set explicitly by  | 
2380  |  | ** [sqlite3_set_last_insert_rowid()]  | 
2381  |  | **  | 
2382  |  | ** Some virtual table implementations may INSERT rows into rowid tables as  | 
2383  |  | ** part of committing a transaction (e.g. to flush data accumulated in memory  | 
2384  |  | ** to disk). In this case subsequent calls to this function return the rowid  | 
2385  |  | ** associated with these internal INSERT operations, which leads to  | 
2386  |  | ** unintuitive results. Virtual table implementations that do write to rowid  | 
2387  |  | ** tables in this way can avoid this problem by restoring the original  | 
2388  |  | ** rowid value using [sqlite3_set_last_insert_rowid()] before returning  | 
2389  |  | ** control to the user.  | 
2390  |  | **  | 
2391  |  | ** ^(If an [INSERT] occurs within a trigger then this routine will  | 
2392  |  | ** return the [rowid] of the inserted row as long as the trigger is  | 
2393  |  | ** running. Once the trigger program ends, the value returned  | 
2394  |  | ** by this routine reverts to what it was before the trigger was fired.)^  | 
2395  |  | **  | 
2396  |  | ** ^An [INSERT] that fails due to a constraint violation is not a  | 
2397  |  | ** successful [INSERT] and does not change the value returned by this  | 
2398  |  | ** routine.  ^Thus INSERT OR FAIL, INSERT OR IGNORE, INSERT OR ROLLBACK,  | 
2399  |  | ** and INSERT OR ABORT make no changes to the return value of this  | 
2400  |  | ** routine when their insertion fails.  ^(When INSERT OR REPLACE  | 
2401  |  | ** encounters a constraint violation, it does not fail.  The  | 
2402  |  | ** INSERT continues to completion after deleting rows that caused  | 
2403  |  | ** the constraint problem so INSERT OR REPLACE will always change  | 
2404  |  | ** the return value of this interface.)^  | 
2405  |  | **  | 
2406  |  | ** ^For the purposes of this routine, an [INSERT] is considered to  | 
2407  |  | ** be successful even if it is subsequently rolled back.  | 
2408  |  | **  | 
2409  |  | ** This function is accessible to SQL statements via the  | 
2410  |  | ** [last_insert_rowid() SQL function].  | 
2411  |  | **  | 
2412  |  | ** If a separate thread performs a new [INSERT] on the same  | 
2413  |  | ** database connection while the [sqlite3_last_insert_rowid()]  | 
2414  |  | ** function is running and thus changes the last insert [rowid],  | 
2415  |  | ** then the value returned by [sqlite3_last_insert_rowid()] is  | 
2416  |  | ** unpredictable and might not equal either the old or the new  | 
2417  |  | ** last insert [rowid].  | 
2418  |  | */  | 
2419  |  | SQLITE_API sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*);  | 
2420  |  |  | 
2421  |  | /*  | 
2422  |  | ** CAPI3REF: Set the Last Insert Rowid value.  | 
2423  |  | ** METHOD: sqlite3  | 
2424  |  | **  | 
2425  |  | ** The sqlite3_set_last_insert_rowid(D, R) method allows the application to  | 
2426  |  | ** set the value returned by calling sqlite3_last_insert_rowid(D) to R  | 
2427  |  | ** without inserting a row into the database.  | 
2428  |  | */  | 
2429  |  | SQLITE_API void sqlite3_set_last_insert_rowid(sqlite3*,sqlite3_int64);  | 
2430  |  |  | 
2431  |  | /*  | 
2432  |  | ** CAPI3REF: Count The Number Of Rows Modified  | 
2433  |  | ** METHOD: sqlite3  | 
2434  |  | **  | 
2435  |  | ** ^This function returns the number of rows modified, inserted or  | 
2436  |  | ** deleted by the most recently completed INSERT, UPDATE or DELETE  | 
2437  |  | ** statement on the database connection specified by the only parameter.  | 
2438  |  | ** ^Executing any other type of SQL statement does not modify the value  | 
2439  |  | ** returned by this function.  | 
2440  |  | **  | 
2441  |  | ** ^Only changes made directly by the INSERT, UPDATE or DELETE statement are  | 
2442  |  | ** considered - auxiliary changes caused by [CREATE TRIGGER | triggers],  | 
2443  |  | ** [foreign key actions] or [REPLACE] constraint resolution are not counted.  | 
2444  |  | **  | 
2445  |  | ** Changes to a view that are intercepted by  | 
2446  |  | ** [INSTEAD OF trigger | INSTEAD OF triggers] are not counted. ^The value  | 
2447  |  | ** returned by sqlite3_changes() immediately after an INSERT, UPDATE or  | 
2448  |  | ** DELETE statement run on a view is always zero. Only changes made to real  | 
2449  |  | ** tables are counted.  | 
2450  |  | **  | 
2451  |  | ** Things are more complicated if the sqlite3_changes() function is  | 
2452  |  | ** executed while a trigger program is running. This may happen if the  | 
2453  |  | ** program uses the [changes() SQL function], or if some other callback  | 
2454  |  | ** function invokes sqlite3_changes() directly. Essentially:  | 
2455  |  | **  | 
2456  |  | ** <ul>  | 
2457  |  | **   <li> ^(Before entering a trigger program the value returned by  | 
2458  |  | **        sqlite3_changes() function is saved. After the trigger program  | 
2459  |  | **        has finished, the original value is restored.)^  | 
2460  |  | **  | 
2461  |  | **   <li> ^(Within a trigger program each INSERT, UPDATE and DELETE  | 
2462  |  | **        statement sets the value returned by sqlite3_changes()  | 
2463  |  | **        upon completion as normal. Of course, this value will not include  | 
2464  |  | **        any changes performed by sub-triggers, as the sqlite3_changes()  | 
2465  |  | **        value will be saved and restored after each sub-trigger has run.)^  | 
2466  |  | ** </ul>  | 
2467  |  | **  | 
2468  |  | ** ^This means that if the changes() SQL function (or similar) is used  | 
2469  |  | ** by the first INSERT, UPDATE or DELETE statement within a trigger, it  | 
2470  |  | ** returns the value as set when the calling statement began executing.  | 
2471  |  | ** ^If it is used by the second or subsequent such statement within a trigger  | 
2472  |  | ** program, the value returned reflects the number of rows modified by the  | 
2473  |  | ** previous INSERT, UPDATE or DELETE statement within the same trigger.  | 
2474  |  | **  | 
2475  |  | ** If a separate thread makes changes on the same database connection  | 
2476  |  | ** while [sqlite3_changes()] is running then the value returned  | 
2477  |  | ** is unpredictable and not meaningful.  | 
2478  |  | **  | 
2479  |  | ** See also:  | 
2480  |  | ** <ul>  | 
2481  |  | ** <li> the [sqlite3_total_changes()] interface  | 
2482  |  | ** <li> the [count_changes pragma]  | 
2483  |  | ** <li> the [changes() SQL function]  | 
2484  |  | ** <li> the [data_version pragma]  | 
2485  |  | ** </ul>  | 
2486  |  | */  | 
2487  |  | SQLITE_API int sqlite3_changes(sqlite3*);  | 
2488  |  |  | 
2489  |  | /*  | 
2490  |  | ** CAPI3REF: Total Number Of Rows Modified  | 
2491  |  | ** METHOD: sqlite3  | 
2492  |  | **  | 
2493  |  | ** ^This function returns the total number of rows inserted, modified or  | 
2494  |  | ** deleted by all [INSERT], [UPDATE] or [DELETE] statements completed  | 
2495  |  | ** since the database connection was opened, including those executed as  | 
2496  |  | ** part of trigger programs. ^Executing any other type of SQL statement  | 
2497  |  | ** does not affect the value returned by sqlite3_total_changes().  | 
2498  |  | **  | 
2499  |  | ** ^Changes made as part of [foreign key actions] are included in the  | 
2500  |  | ** count, but those made as part of REPLACE constraint resolution are  | 
2501  |  | ** not. ^Changes to a view that are intercepted by INSTEAD OF triggers  | 
2502  |  | ** are not counted.  | 
2503  |  | **  | 
2504  |  | ** The [sqlite3_total_changes(D)] interface only reports the number  | 
2505  |  | ** of rows that changed due to SQL statement run against database  | 
2506  |  | ** connection D.  Any changes by other database connections are ignored.  | 
2507  |  | ** To detect changes against a database file from other database  | 
2508  |  | ** connections use the [PRAGMA data_version] command or the  | 
2509  |  | ** [SQLITE_FCNTL_DATA_VERSION] [file control].  | 
2510  |  | **  | 
2511  |  | ** If a separate thread makes changes on the same database connection  | 
2512  |  | ** while [sqlite3_total_changes()] is running then the value  | 
2513  |  | ** returned is unpredictable and not meaningful.  | 
2514  |  | **  | 
2515  |  | ** See also:  | 
2516  |  | ** <ul>  | 
2517  |  | ** <li> the [sqlite3_changes()] interface  | 
2518  |  | ** <li> the [count_changes pragma]  | 
2519  |  | ** <li> the [changes() SQL function]  | 
2520  |  | ** <li> the [data_version pragma]  | 
2521  |  | ** <li> the [SQLITE_FCNTL_DATA_VERSION] [file control]  | 
2522  |  | ** </ul>  | 
2523  |  | */  | 
2524  |  | SQLITE_API int sqlite3_total_changes(sqlite3*);  | 
2525  |  |  | 
2526  |  | /*  | 
2527  |  | ** CAPI3REF: Interrupt A Long-Running Query  | 
2528  |  | ** METHOD: sqlite3  | 
2529  |  | **  | 
2530  |  | ** ^This function causes any pending database operation to abort and  | 
2531  |  | ** return at its earliest opportunity. This routine is typically  | 
2532  |  | ** called in response to a user action such as pressing "Cancel"  | 
2533  |  | ** or Ctrl-C where the user wants a long query operation to halt  | 
2534  |  | ** immediately.  | 
2535  |  | **  | 
2536  |  | ** ^It is safe to call this routine from a thread different from the  | 
2537  |  | ** thread that is currently running the database operation.  But it  | 
2538  |  | ** is not safe to call this routine with a [database connection] that  | 
2539  |  | ** is closed or might close before sqlite3_interrupt() returns.  | 
2540  |  | **  | 
2541  |  | ** ^If an SQL operation is very nearly finished at the time when  | 
2542  |  | ** sqlite3_interrupt() is called, then it might not have an opportunity  | 
2543  |  | ** to be interrupted and might continue to completion.  | 
2544  |  | **  | 
2545  |  | ** ^An SQL operation that is interrupted will return [SQLITE_INTERRUPT].  | 
2546  |  | ** ^If the interrupted SQL operation is an INSERT, UPDATE, or DELETE  | 
2547  |  | ** that is inside an explicit transaction, then the entire transaction  | 
2548  |  | ** will be rolled back automatically.  | 
2549  |  | **  | 
2550  |  | ** ^The sqlite3_interrupt(D) call is in effect until all currently running  | 
2551  |  | ** SQL statements on [database connection] D complete.  ^Any new SQL statements  | 
2552  |  | ** that are started after the sqlite3_interrupt() call and before the  | 
2553  |  | ** running statement count reaches zero are interrupted as if they had been  | 
2554  |  | ** running prior to the sqlite3_interrupt() call.  ^New SQL statements  | 
2555  |  | ** that are started after the running statement count reaches zero are  | 
2556  |  | ** not effected by the sqlite3_interrupt().  | 
2557  |  | ** ^A call to sqlite3_interrupt(D) that occurs when there are no running  | 
2558  |  | ** SQL statements is a no-op and has no effect on SQL statements  | 
2559  |  | ** that are started after the sqlite3_interrupt() call returns.  | 
2560  |  | */  | 
2561  |  | SQLITE_API void sqlite3_interrupt(sqlite3*);  | 
2562  |  |  | 
2563  |  | /*  | 
2564  |  | ** CAPI3REF: Determine If An SQL Statement Is Complete  | 
2565  |  | **  | 
2566  |  | ** These routines are useful during command-line input to determine if the  | 
2567  |  | ** currently entered text seems to form a complete SQL statement or  | 
2568  |  | ** if additional input is needed before sending the text into  | 
2569  |  | ** SQLite for parsing.  ^These routines return 1 if the input string  | 
2570  |  | ** appears to be a complete SQL statement.  ^A statement is judged to be  | 
2571  |  | ** complete if it ends with a semicolon token and is not a prefix of a  | 
2572  |  | ** well-formed CREATE TRIGGER statement.  ^Semicolons that are embedded within  | 
2573  |  | ** string literals or quoted identifier names or comments are not  | 
2574  |  | ** independent tokens (they are part of the token in which they are  | 
2575  |  | ** embedded) and thus do not count as a statement terminator.  ^Whitespace  | 
2576  |  | ** and comments that follow the final semicolon are ignored.  | 
2577  |  | **  | 
2578  |  | ** ^These routines return 0 if the statement is incomplete.  ^If a  | 
2579  |  | ** memory allocation fails, then SQLITE_NOMEM is returned.  | 
2580  |  | **  | 
2581  |  | ** ^These routines do not parse the SQL statements thus  | 
2582  |  | ** will not detect syntactically incorrect SQL.  | 
2583  |  | **  | 
2584  |  | ** ^(If SQLite has not been initialized using [sqlite3_initialize()] prior  | 
2585  |  | ** to invoking sqlite3_complete16() then sqlite3_initialize() is invoked  | 
2586  |  | ** automatically by sqlite3_complete16().  If that initialization fails,  | 
2587  |  | ** then the return value from sqlite3_complete16() will be non-zero  | 
2588  |  | ** regardless of whether or not the input SQL is complete.)^  | 
2589  |  | **  | 
2590  |  | ** The input to [sqlite3_complete()] must be a zero-terminated  | 
2591  |  | ** UTF-8 string.  | 
2592  |  | **  | 
2593  |  | ** The input to [sqlite3_complete16()] must be a zero-terminated  | 
2594  |  | ** UTF-16 string in native byte order.  | 
2595  |  | */  | 
2596  |  | SQLITE_API int sqlite3_complete(const char *sql);  | 
2597  |  | SQLITE_API int sqlite3_complete16(const void *sql);  | 
2598  |  |  | 
2599  |  | /*  | 
2600  |  | ** CAPI3REF: Register A Callback To Handle SQLITE_BUSY Errors  | 
2601  |  | ** KEYWORDS: {busy-handler callback} {busy handler} | 
2602  |  | ** METHOD: sqlite3  | 
2603  |  | **  | 
2604  |  | ** ^The sqlite3_busy_handler(D,X,P) routine sets a callback function X  | 
2605  |  | ** that might be invoked with argument P whenever  | 
2606  |  | ** an attempt is made to access a database table associated with  | 
2607  |  | ** [database connection] D when another thread  | 
2608  |  | ** or process has the table locked.  | 
2609  |  | ** The sqlite3_busy_handler() interface is used to implement  | 
2610  |  | ** [sqlite3_busy_timeout()] and [PRAGMA busy_timeout].  | 
2611  |  | **  | 
2612  |  | ** ^If the busy callback is NULL, then [SQLITE_BUSY]  | 
2613  |  | ** is returned immediately upon encountering the lock.  ^If the busy callback  | 
2614  |  | ** is not NULL, then the callback might be invoked with two arguments.  | 
2615  |  | **  | 
2616  |  | ** ^The first argument to the busy handler is a copy of the void* pointer which  | 
2617  |  | ** is the third argument to sqlite3_busy_handler().  ^The second argument to  | 
2618  |  | ** the busy handler callback is the number of times that the busy handler has  | 
2619  |  | ** been invoked previously for the same locking event.  ^If the  | 
2620  |  | ** busy callback returns 0, then no additional attempts are made to  | 
2621  |  | ** access the database and [SQLITE_BUSY] is returned  | 
2622  |  | ** to the application.  | 
2623  |  | ** ^If the callback returns non-zero, then another attempt  | 
2624  |  | ** is made to access the database and the cycle repeats.  | 
2625  |  | **  | 
2626  |  | ** The presence of a busy handler does not guarantee that it will be invoked  | 
2627  |  | ** when there is lock contention. ^If SQLite determines that invoking the busy  | 
2628  |  | ** handler could result in a deadlock, it will go ahead and return [SQLITE_BUSY]  | 
2629  |  | ** to the application instead of invoking the  | 
2630  |  | ** busy handler.  | 
2631  |  | ** Consider a scenario where one process is holding a read lock that  | 
2632  |  | ** it is trying to promote to a reserved lock and  | 
2633  |  | ** a second process is holding a reserved lock that it is trying  | 
2634  |  | ** to promote to an exclusive lock.  The first process cannot proceed  | 
2635  |  | ** because it is blocked by the second and the second process cannot  | 
2636  |  | ** proceed because it is blocked by the first.  If both processes  | 
2637  |  | ** invoke the busy handlers, neither will make any progress.  Therefore,  | 
2638  |  | ** SQLite returns [SQLITE_BUSY] for the first process, hoping that this  | 
2639  |  | ** will induce the first process to release its read lock and allow  | 
2640  |  | ** the second process to proceed.  | 
2641  |  | **  | 
2642  |  | ** ^The default busy callback is NULL.  | 
2643  |  | **  | 
2644  |  | ** ^(There can only be a single busy handler defined for each  | 
2645  |  | ** [database connection].  Setting a new busy handler clears any  | 
2646  |  | ** previously set handler.)^  ^Note that calling [sqlite3_busy_timeout()]  | 
2647  |  | ** or evaluating [PRAGMA busy_timeout=N] will change the  | 
2648  |  | ** busy handler and thus clear any previously set busy handler.  | 
2649  |  | **  | 
2650  |  | ** The busy callback should not take any actions which modify the  | 
2651  |  | ** database connection that invoked the busy handler.  In other words,  | 
2652  |  | ** the busy handler is not reentrant.  Any such actions  | 
2653  |  | ** result in undefined behavior.  | 
2654  |  | **  | 
2655  |  | ** A busy handler must not close the database connection  | 
2656  |  | ** or [prepared statement] that invoked the busy handler.  | 
2657  |  | */  | 
2658  |  | SQLITE_API int sqlite3_busy_handler(sqlite3*,int(*)(void*,int),void*);  | 
2659  |  |  | 
2660  |  | /*  | 
2661  |  | ** CAPI3REF: Set A Busy Timeout  | 
2662  |  | ** METHOD: sqlite3  | 
2663  |  | **  | 
2664  |  | ** ^This routine sets a [sqlite3_busy_handler | busy handler] that sleeps  | 
2665  |  | ** for a specified amount of time when a table is locked.  ^The handler  | 
2666  |  | ** will sleep multiple times until at least "ms" milliseconds of sleeping  | 
2667  |  | ** have accumulated.  ^After at least "ms" milliseconds of sleeping,  | 
2668  |  | ** the handler returns 0 which causes [sqlite3_step()] to return  | 
2669  |  | ** [SQLITE_BUSY].  | 
2670  |  | **  | 
2671  |  | ** ^Calling this routine with an argument less than or equal to zero  | 
2672  |  | ** turns off all busy handlers.  | 
2673  |  | **  | 
2674  |  | ** ^(There can only be a single busy handler for a particular  | 
2675  |  | ** [database connection] at any given moment.  If another busy handler  | 
2676  |  | ** was defined  (using [sqlite3_busy_handler()]) prior to calling  | 
2677  |  | ** this routine, that other busy handler is cleared.)^  | 
2678  |  | **  | 
2679  |  | ** See also:  [PRAGMA busy_timeout]  | 
2680  |  | */  | 
2681  |  | SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms);  | 
2682  |  |  | 
2683  |  | /*  | 
2684  |  | ** CAPI3REF: Convenience Routines For Running Queries  | 
2685  |  | ** METHOD: sqlite3  | 
2686  |  | **  | 
2687  |  | ** This is a legacy interface that is preserved for backwards compatibility.  | 
2688  |  | ** Use of this interface is not recommended.  | 
2689  |  | **  | 
2690  |  | ** Definition: A <b>result table</b> is memory data structure created by the  | 
2691  |  | ** [sqlite3_get_table()] interface.  A result table records the  | 
2692  |  | ** complete query results from one or more queries.  | 
2693  |  | **  | 
2694  |  | ** The table conceptually has a number of rows and columns.  But  | 
2695  |  | ** these numbers are not part of the result table itself.  These  | 
2696  |  | ** numbers are obtained separately.  Let N be the number of rows  | 
2697  |  | ** and M be the number of columns.  | 
2698  |  | **  | 
2699  |  | ** A result table is an array of pointers to zero-terminated UTF-8 strings.  | 
2700  |  | ** There are (N+1)*M elements in the array.  The first M pointers point  | 
2701  |  | ** to zero-terminated strings that  contain the names of the columns.  | 
2702  |  | ** The remaining entries all point to query results.  NULL values result  | 
2703  |  | ** in NULL pointers.  All other values are in their UTF-8 zero-terminated  | 
2704  |  | ** string representation as returned by [sqlite3_column_text()].  | 
2705  |  | **  | 
2706  |  | ** A result table might consist of one or more memory allocations.  | 
2707  |  | ** It is not safe to pass a result table directly to [sqlite3_free()].  | 
2708  |  | ** A result table should be deallocated using [sqlite3_free_table()].  | 
2709  |  | **  | 
2710  |  | ** ^(As an example of the result table format, suppose a query result  | 
2711  |  | ** is as follows:  | 
2712  |  | **  | 
2713  |  | ** <blockquote><pre>  | 
2714  |  | **        Name        | Age  | 
2715  |  | **        -----------------------  | 
2716  |  | **        Alice       | 43  | 
2717  |  | **        Bob         | 28  | 
2718  |  | **        Cindy       | 21  | 
2719  |  | ** </pre></blockquote>  | 
2720  |  | **  | 
2721  |  | ** There are two columns (M==2) and three rows (N==3).  Thus the  | 
2722  |  | ** result table has 8 entries.  Suppose the result table is stored  | 
2723  |  | ** in an array named azResult.  Then azResult holds this content:  | 
2724  |  | **  | 
2725  |  | ** <blockquote><pre>  | 
2726  |  | **        azResult[0] = "Name";  | 
2727  |  | **        azResult[1] = "Age";  | 
2728  |  | **        azResult[2] = "Alice";  | 
2729  |  | **        azResult[3] = "43";  | 
2730  |  | **        azResult[4] = "Bob";  | 
2731  |  | **        azResult[5] = "28";  | 
2732  |  | **        azResult[6] = "Cindy";  | 
2733  |  | **        azResult[7] = "21";  | 
2734  |  | ** </pre></blockquote>)^  | 
2735  |  | **  | 
2736  |  | ** ^The sqlite3_get_table() function evaluates one or more  | 
2737  |  | ** semicolon-separated SQL statements in the zero-terminated UTF-8  | 
2738  |  | ** string of its 2nd parameter and returns a result table to the  | 
2739  |  | ** pointer given in its 3rd parameter.  | 
2740  |  | **  | 
2741  |  | ** After the application has finished with the result from sqlite3_get_table(),  | 
2742  |  | ** it must pass the result table pointer to sqlite3_free_table() in order to  | 
2743  |  | ** release the memory that was malloced.  Because of the way the  | 
2744  |  | ** [sqlite3_malloc()] happens within sqlite3_get_table(), the calling  | 
2745  |  | ** function must not try to call [sqlite3_free()] directly.  Only  | 
2746  |  | ** [sqlite3_free_table()] is able to release the memory properly and safely.  | 
2747  |  | **  | 
2748  |  | ** The sqlite3_get_table() interface is implemented as a wrapper around  | 
2749  |  | ** [sqlite3_exec()].  The sqlite3_get_table() routine does not have access  | 
2750  |  | ** to any internal data structures of SQLite.  It uses only the public  | 
2751  |  | ** interface defined here.  As a consequence, errors that occur in the  | 
2752  |  | ** wrapper layer outside of the internal [sqlite3_exec()] call are not  | 
2753  |  | ** reflected in subsequent calls to [sqlite3_errcode()] or  | 
2754  |  | ** [sqlite3_errmsg()].  | 
2755  |  | */  | 
2756  |  | SQLITE_API int sqlite3_get_table(  | 
2757  |  |   sqlite3 *db,          /* An open database */  | 
2758  |  |   const char *zSql,     /* SQL to be evaluated */  | 
2759  |  |   char ***pazResult,    /* Results of the query */  | 
2760  |  |   int *pnRow,           /* Number of result rows written here */  | 
2761  |  |   int *pnColumn,        /* Number of result columns written here */  | 
2762  |  |   char **pzErrmsg       /* Error msg written here */  | 
2763  |  | );  | 
2764  |  | SQLITE_API void sqlite3_free_table(char **result);  | 
2765  |  |  | 
2766  |  | /*  | 
2767  |  | ** CAPI3REF: Formatted String Printing Functions  | 
2768  |  | **  | 
2769  |  | ** These routines are work-alikes of the "printf()" family of functions  | 
2770  |  | ** from the standard C library.  | 
2771  |  | ** These routines understand most of the common formatting options from  | 
2772  |  | ** the standard library printf()  | 
2773  |  | ** plus some additional non-standard formats ([%q], [%Q], [%w], and [%z]).  | 
2774  |  | ** See the [built-in printf()] documentation for details.  | 
2775  |  | **  | 
2776  |  | ** ^The sqlite3_mprintf() and sqlite3_vmprintf() routines write their  | 
2777  |  | ** results into memory obtained from [sqlite3_malloc64()].  | 
2778  |  | ** The strings returned by these two routines should be  | 
2779  |  | ** released by [sqlite3_free()].  ^Both routines return a  | 
2780  |  | ** NULL pointer if [sqlite3_malloc64()] is unable to allocate enough  | 
2781  |  | ** memory to hold the resulting string.  | 
2782  |  | **  | 
2783  |  | ** ^(The sqlite3_snprintf() routine is similar to "snprintf()" from  | 
2784  |  | ** the standard C library.  The result is written into the  | 
2785  |  | ** buffer supplied as the second parameter whose size is given by  | 
2786  |  | ** the first parameter. Note that the order of the  | 
2787  |  | ** first two parameters is reversed from snprintf().)^  This is an  | 
2788  |  | ** historical accident that cannot be fixed without breaking  | 
2789  |  | ** backwards compatibility.  ^(Note also that sqlite3_snprintf()  | 
2790  |  | ** returns a pointer to its buffer instead of the number of  | 
2791  |  | ** characters actually written into the buffer.)^  We admit that  | 
2792  |  | ** the number of characters written would be a more useful return  | 
2793  |  | ** value but we cannot change the implementation of sqlite3_snprintf()  | 
2794  |  | ** now without breaking compatibility.  | 
2795  |  | **  | 
2796  |  | ** ^As long as the buffer size is greater than zero, sqlite3_snprintf()  | 
2797  |  | ** guarantees that the buffer is always zero-terminated.  ^The first  | 
2798  |  | ** parameter "n" is the total size of the buffer, including space for  | 
2799  |  | ** the zero terminator.  So the longest string that can be completely  | 
2800  |  | ** written will be n-1 characters.  | 
2801  |  | **  | 
2802  |  | ** ^The sqlite3_vsnprintf() routine is a varargs version of sqlite3_snprintf().  | 
2803  |  | **  | 
2804  |  | ** See also:  [built-in printf()], [printf() SQL function]  | 
2805  |  | */  | 
2806  |  | SQLITE_API char *sqlite3_mprintf(const char*,...);  | 
2807  |  | SQLITE_API char *sqlite3_vmprintf(const char*, va_list);  | 
2808  |  | SQLITE_API char *sqlite3_snprintf(int,char*,const char*, ...);  | 
2809  |  | SQLITE_API char *sqlite3_vsnprintf(int,char*,const char*, va_list);  | 
2810  |  |  | 
2811  |  | /*  | 
2812  |  | ** CAPI3REF: Memory Allocation Subsystem  | 
2813  |  | **  | 
2814  |  | ** The SQLite core uses these three routines for all of its own  | 
2815  |  | ** internal memory allocation needs. "Core" in the previous sentence  | 
2816  |  | ** does not include operating-system specific [VFS] implementation.  The  | 
2817  |  | ** Windows VFS uses native malloc() and free() for some operations.  | 
2818  |  | **  | 
2819  |  | ** ^The sqlite3_malloc() routine returns a pointer to a block  | 
2820  |  | ** of memory at least N bytes in length, where N is the parameter.  | 
2821  |  | ** ^If sqlite3_malloc() is unable to obtain sufficient free  | 
2822  |  | ** memory, it returns a NULL pointer.  ^If the parameter N to  | 
2823  |  | ** sqlite3_malloc() is zero or negative then sqlite3_malloc() returns  | 
2824  |  | ** a NULL pointer.  | 
2825  |  | **  | 
2826  |  | ** ^The sqlite3_malloc64(N) routine works just like  | 
2827  |  | ** sqlite3_malloc(N) except that N is an unsigned 64-bit integer instead  | 
2828  |  | ** of a signed 32-bit integer.  | 
2829  |  | **  | 
2830  |  | ** ^Calling sqlite3_free() with a pointer previously returned  | 
2831  |  | ** by sqlite3_malloc() or sqlite3_realloc() releases that memory so  | 
2832  |  | ** that it might be reused.  ^The sqlite3_free() routine is  | 
2833  |  | ** a no-op if is called with a NULL pointer.  Passing a NULL pointer  | 
2834  |  | ** to sqlite3_free() is harmless.  After being freed, memory  | 
2835  |  | ** should neither be read nor written.  Even reading previously freed  | 
2836  |  | ** memory might result in a segmentation fault or other severe error.  | 
2837  |  | ** Memory corruption, a segmentation fault, or other severe error  | 
2838  |  | ** might result if sqlite3_free() is called with a non-NULL pointer that  | 
2839  |  | ** was not obtained from sqlite3_malloc() or sqlite3_realloc().  | 
2840  |  | **  | 
2841  |  | ** ^The sqlite3_realloc(X,N) interface attempts to resize a  | 
2842  |  | ** prior memory allocation X to be at least N bytes.  | 
2843  |  | ** ^If the X parameter to sqlite3_realloc(X,N)  | 
2844  |  | ** is a NULL pointer then its behavior is identical to calling  | 
2845  |  | ** sqlite3_malloc(N).  | 
2846  |  | ** ^If the N parameter to sqlite3_realloc(X,N) is zero or  | 
2847  |  | ** negative then the behavior is exactly the same as calling  | 
2848  |  | ** sqlite3_free(X).  | 
2849  |  | ** ^sqlite3_realloc(X,N) returns a pointer to a memory allocation  | 
2850  |  | ** of at least N bytes in size or NULL if insufficient memory is available.  | 
2851  |  | ** ^If M is the size of the prior allocation, then min(N,M) bytes  | 
2852  |  | ** of the prior allocation are copied into the beginning of buffer returned  | 
2853  |  | ** by sqlite3_realloc(X,N) and the prior allocation is freed.  | 
2854  |  | ** ^If sqlite3_realloc(X,N) returns NULL and N is positive, then the  | 
2855  |  | ** prior allocation is not freed.  | 
2856  |  | **  | 
2857  |  | ** ^The sqlite3_realloc64(X,N) interfaces works the same as  | 
2858  |  | ** sqlite3_realloc(X,N) except that N is a 64-bit unsigned integer instead  | 
2859  |  | ** of a 32-bit signed integer.  | 
2860  |  | **  | 
2861  |  | ** ^If X is a memory allocation previously obtained from sqlite3_malloc(),  | 
2862  |  | ** sqlite3_malloc64(), sqlite3_realloc(), or sqlite3_realloc64(), then  | 
2863  |  | ** sqlite3_msize(X) returns the size of that memory allocation in bytes.  | 
2864  |  | ** ^The value returned by sqlite3_msize(X) might be larger than the number  | 
2865  |  | ** of bytes requested when X was allocated.  ^If X is a NULL pointer then  | 
2866  |  | ** sqlite3_msize(X) returns zero.  If X points to something that is not  | 
2867  |  | ** the beginning of memory allocation, or if it points to a formerly  | 
2868  |  | ** valid memory allocation that has now been freed, then the behavior  | 
2869  |  | ** of sqlite3_msize(X) is undefined and possibly harmful.  | 
2870  |  | **  | 
2871  |  | ** ^The memory returned by sqlite3_malloc(), sqlite3_realloc(),  | 
2872  |  | ** sqlite3_malloc64(), and sqlite3_realloc64()  | 
2873  |  | ** is always aligned to at least an 8 byte boundary, or to a  | 
2874  |  | ** 4 byte boundary if the [SQLITE_4_BYTE_ALIGNED_MALLOC] compile-time  | 
2875  |  | ** option is used.  | 
2876  |  | **  | 
2877  |  | ** The pointer arguments to [sqlite3_free()] and [sqlite3_realloc()]  | 
2878  |  | ** must be either NULL or else pointers obtained from a prior  | 
2879  |  | ** invocation of [sqlite3_malloc()] or [sqlite3_realloc()] that have  | 
2880  |  | ** not yet been released.  | 
2881  |  | **  | 
2882  |  | ** The application must not read or write any part of  | 
2883  |  | ** a block of memory after it has been released using  | 
2884  |  | ** [sqlite3_free()] or [sqlite3_realloc()].  | 
2885  |  | */  | 
2886  |  | SQLITE_API void *sqlite3_malloc(int);  | 
2887  |  | SQLITE_API void *sqlite3_malloc64(sqlite3_uint64);  | 
2888  |  | SQLITE_API void *sqlite3_realloc(void*, int);  | 
2889  |  | SQLITE_API void *sqlite3_realloc64(void*, sqlite3_uint64);  | 
2890  |  | SQLITE_API void sqlite3_free(void*);  | 
2891  |  | SQLITE_API sqlite3_uint64 sqlite3_msize(void*);  | 
2892  |  |  | 
2893  |  | /*  | 
2894  |  | ** CAPI3REF: Memory Allocator Statistics  | 
2895  |  | **  | 
2896  |  | ** SQLite provides these two interfaces for reporting on the status  | 
2897  |  | ** of the [sqlite3_malloc()], [sqlite3_free()], and [sqlite3_realloc()]  | 
2898  |  | ** routines, which form the built-in memory allocation subsystem.  | 
2899  |  | **  | 
2900  |  | ** ^The [sqlite3_memory_used()] routine returns the number of bytes  | 
2901  |  | ** of memory currently outstanding (malloced but not freed).  | 
2902  |  | ** ^The [sqlite3_memory_highwater()] routine returns the maximum  | 
2903  |  | ** value of [sqlite3_memory_used()] since the high-water mark  | 
2904  |  | ** was last reset.  ^The values returned by [sqlite3_memory_used()] and  | 
2905  |  | ** [sqlite3_memory_highwater()] include any overhead  | 
2906  |  | ** added by SQLite in its implementation of [sqlite3_malloc()],  | 
2907  |  | ** but not overhead added by the any underlying system library  | 
2908  |  | ** routines that [sqlite3_malloc()] may call.  | 
2909  |  | **  | 
2910  |  | ** ^The memory high-water mark is reset to the current value of  | 
2911  |  | ** [sqlite3_memory_used()] if and only if the parameter to  | 
2912  |  | ** [sqlite3_memory_highwater()] is true.  ^The value returned  | 
2913  |  | ** by [sqlite3_memory_highwater(1)] is the high-water mark  | 
2914  |  | ** prior to the reset.  | 
2915  |  | */  | 
2916  |  | SQLITE_API sqlite3_int64 sqlite3_memory_used(void);  | 
2917  |  | SQLITE_API sqlite3_int64 sqlite3_memory_highwater(int resetFlag);  | 
2918  |  |  | 
2919  |  | /*  | 
2920  |  | ** CAPI3REF: Pseudo-Random Number Generator  | 
2921  |  | **  | 
2922  |  | ** SQLite contains a high-quality pseudo-random number generator (PRNG) used to  | 
2923  |  | ** select random [ROWID | ROWIDs] when inserting new records into a table that  | 
2924  |  | ** already uses the largest possible [ROWID].  The PRNG is also used for  | 
2925  |  | ** the built-in random() and randomblob() SQL functions.  This interface allows  | 
2926  |  | ** applications to access the same PRNG for other purposes.  | 
2927  |  | **  | 
2928  |  | ** ^A call to this routine stores N bytes of randomness into buffer P.  | 
2929  |  | ** ^The P parameter can be a NULL pointer.  | 
2930  |  | **  | 
2931  |  | ** ^If this routine has not been previously called or if the previous  | 
2932  |  | ** call had N less than one or a NULL pointer for P, then the PRNG is  | 
2933  |  | ** seeded using randomness obtained from the xRandomness method of  | 
2934  |  | ** the default [sqlite3_vfs] object.  | 
2935  |  | ** ^If the previous call to this routine had an N of 1 or more and a  | 
2936  |  | ** non-NULL P then the pseudo-randomness is generated  | 
2937  |  | ** internally and without recourse to the [sqlite3_vfs] xRandomness  | 
2938  |  | ** method.  | 
2939  |  | */  | 
2940  |  | SQLITE_API void sqlite3_randomness(int N, void *P);  | 
2941  |  |  | 
2942  |  | /*  | 
2943  |  | ** CAPI3REF: Compile-Time Authorization Callbacks  | 
2944  |  | ** METHOD: sqlite3  | 
2945  |  | ** KEYWORDS: {authorizer callback} | 
2946  |  | **  | 
2947  |  | ** ^This routine registers an authorizer callback with a particular  | 
2948  |  | ** [database connection], supplied in the first argument.  | 
2949  |  | ** ^The authorizer callback is invoked as SQL statements are being compiled  | 
2950  |  | ** by [sqlite3_prepare()] or its variants [sqlite3_prepare_v2()],  | 
2951  |  | ** [sqlite3_prepare_v3()], [sqlite3_prepare16()], [sqlite3_prepare16_v2()],  | 
2952  |  | ** and [sqlite3_prepare16_v3()].  ^At various  | 
2953  |  | ** points during the compilation process, as logic is being created  | 
2954  |  | ** to perform various actions, the authorizer callback is invoked to  | 
2955  |  | ** see if those actions are allowed.  ^The authorizer callback should  | 
2956  |  | ** return [SQLITE_OK] to allow the action, [SQLITE_IGNORE] to disallow the  | 
2957  |  | ** specific action but allow the SQL statement to continue to be  | 
2958  |  | ** compiled, or [SQLITE_DENY] to cause the entire SQL statement to be  | 
2959  |  | ** rejected with an error.  ^If the authorizer callback returns  | 
2960  |  | ** any value other than [SQLITE_IGNORE], [SQLITE_OK], or [SQLITE_DENY]  | 
2961  |  | ** then the [sqlite3_prepare_v2()] or equivalent call that triggered  | 
2962  |  | ** the authorizer will fail with an error message.  | 
2963  |  | **  | 
2964  |  | ** When the callback returns [SQLITE_OK], that means the operation  | 
2965  |  | ** requested is ok.  ^When the callback returns [SQLITE_DENY], the  | 
2966  |  | ** [sqlite3_prepare_v2()] or equivalent call that triggered the  | 
2967  |  | ** authorizer will fail with an error message explaining that  | 
2968  |  | ** access is denied.  | 
2969  |  | **  | 
2970  |  | ** ^The first parameter to the authorizer callback is a copy of the third  | 
2971  |  | ** parameter to the sqlite3_set_authorizer() interface. ^The second parameter  | 
2972  |  | ** to the callback is an integer [SQLITE_COPY | action code] that specifies  | 
2973  |  | ** the particular action to be authorized. ^The third through sixth parameters  | 
2974  |  | ** to the callback are either NULL pointers or zero-terminated strings  | 
2975  |  | ** that contain additional details about the action to be authorized.  | 
2976  |  | ** Applications must always be prepared to encounter a NULL pointer in any  | 
2977  |  | ** of the third through the sixth parameters of the authorization callback.  | 
2978  |  | **  | 
2979  |  | ** ^If the action code is [SQLITE_READ]  | 
2980  |  | ** and the callback returns [SQLITE_IGNORE] then the  | 
2981  |  | ** [prepared statement] statement is constructed to substitute  | 
2982  |  | ** a NULL value in place of the table column that would have  | 
2983  |  | ** been read if [SQLITE_OK] had been returned.  The [SQLITE_IGNORE]  | 
2984  |  | ** return can be used to deny an untrusted user access to individual  | 
2985  |  | ** columns of a table.  | 
2986  |  | ** ^When a table is referenced by a [SELECT] but no column values are  | 
2987  |  | ** extracted from that table (for example in a query like  | 
2988  |  | ** "SELECT count(*) FROM tab") then the [SQLITE_READ] authorizer callback  | 
2989  |  | ** is invoked once for that table with a column name that is an empty string.  | 
2990  |  | ** ^If the action code is [SQLITE_DELETE] and the callback returns  | 
2991  |  | ** [SQLITE_IGNORE] then the [DELETE] operation proceeds but the  | 
2992  |  | ** [truncate optimization] is disabled and all rows are deleted individually.  | 
2993  |  | **  | 
2994  |  | ** An authorizer is used when [sqlite3_prepare | preparing]  | 
2995  |  | ** SQL statements from an untrusted source, to ensure that the SQL statements  | 
2996  |  | ** do not try to access data they are not allowed to see, or that they do not  | 
2997  |  | ** try to execute malicious statements that damage the database.  For  | 
2998  |  | ** example, an application may allow a user to enter arbitrary  | 
2999  |  | ** SQL queries for evaluation by a database.  But the application does  | 
3000  |  | ** not want the user to be able to make arbitrary changes to the  | 
3001  |  | ** database.  An authorizer could then be put in place while the  | 
3002  |  | ** user-entered SQL is being [sqlite3_prepare | prepared] that  | 
3003  |  | ** disallows everything except [SELECT] statements.  | 
3004  |  | **  | 
3005  |  | ** Applications that need to process SQL from untrusted sources  | 
3006  |  | ** might also consider lowering resource limits using [sqlite3_limit()]  | 
3007  |  | ** and limiting database size using the [max_page_count] [PRAGMA]  | 
3008  |  | ** in addition to using an authorizer.  | 
3009  |  | **  | 
3010  |  | ** ^(Only a single authorizer can be in place on a database connection  | 
3011  |  | ** at a time.  Each call to sqlite3_set_authorizer overrides the  | 
3012  |  | ** previous call.)^  ^Disable the authorizer by installing a NULL callback.  | 
3013  |  | ** The authorizer is disabled by default.  | 
3014  |  | **  | 
3015  |  | ** The authorizer callback must not do anything that will modify  | 
3016  |  | ** the database connection that invoked the authorizer callback.  | 
3017  |  | ** Note that [sqlite3_prepare_v2()] and [sqlite3_step()] both modify their  | 
3018  |  | ** database connections for the meaning of "modify" in this paragraph.  | 
3019  |  | **  | 
3020  |  | ** ^When [sqlite3_prepare_v2()] is used to prepare a statement, the  | 
3021  |  | ** statement might be re-prepared during [sqlite3_step()] due to a  | 
3022  |  | ** schema change.  Hence, the application should ensure that the  | 
3023  |  | ** correct authorizer callback remains in place during the [sqlite3_step()].  | 
3024  |  | **  | 
3025  |  | ** ^Note that the authorizer callback is invoked only during  | 
3026  |  | ** [sqlite3_prepare()] or its variants.  Authorization is not  | 
3027  |  | ** performed during statement evaluation in [sqlite3_step()], unless  | 
3028  |  | ** as stated in the previous paragraph, sqlite3_step() invokes  | 
3029  |  | ** sqlite3_prepare_v2() to reprepare a statement after a schema change.  | 
3030  |  | */  | 
3031  |  | SQLITE_API int sqlite3_set_authorizer(  | 
3032  |  |   sqlite3*,  | 
3033  |  |   int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),  | 
3034  |  |   void *pUserData  | 
3035  |  | );  | 
3036  |  |  | 
3037  |  | /*  | 
3038  |  | ** CAPI3REF: Authorizer Return Codes  | 
3039  |  | **  | 
3040  |  | ** The [sqlite3_set_authorizer | authorizer callback function] must  | 
3041  |  | ** return either [SQLITE_OK] or one of these two constants in order  | 
3042  |  | ** to signal SQLite whether or not the action is permitted.  See the  | 
3043  |  | ** [sqlite3_set_authorizer | authorizer documentation] for additional  | 
3044  |  | ** information.  | 
3045  |  | **  | 
3046  |  | ** Note that SQLITE_IGNORE is also used as a [conflict resolution mode]  | 
3047  |  | ** returned from the [sqlite3_vtab_on_conflict()] interface.  | 
3048  |  | */  | 
3049  | 3  | #define SQLITE_DENY   1   /* Abort the SQL statement with an error */  | 
3050  |  | #define SQLITE_IGNORE 2   /* Don't allow access, but don't generate an error */  | 
3051  |  |  | 
3052  |  | /*  | 
3053  |  | ** CAPI3REF: Authorizer Action Codes  | 
3054  |  | **  | 
3055  |  | ** The [sqlite3_set_authorizer()] interface registers a callback function  | 
3056  |  | ** that is invoked to authorize certain SQL statement actions.  The  | 
3057  |  | ** second parameter to the callback is an integer code that specifies  | 
3058  |  | ** what action is being authorized.  These are the integer action codes that  | 
3059  |  | ** the authorizer callback may be passed.  | 
3060  |  | **  | 
3061  |  | ** These action code values signify what kind of operation is to be  | 
3062  |  | ** authorized.  The 3rd and 4th parameters to the authorization  | 
3063  |  | ** callback function will be parameters or NULL depending on which of these  | 
3064  |  | ** codes is used as the second parameter.  ^(The 5th parameter to the  | 
3065  |  | ** authorizer callback is the name of the database ("main", "temp", | 
3066  |  | ** etc.) if applicable.)^  ^The 6th parameter to the authorizer callback  | 
3067  |  | ** is the name of the inner-most trigger or view that is responsible for  | 
3068  |  | ** the access attempt or NULL if this access attempt is directly from  | 
3069  |  | ** top-level SQL code.  | 
3070  |  | */  | 
3071  |  | /******************************************* 3rd ************ 4th ***********/  | 
3072  |  | #define SQLITE_CREATE_INDEX          1   /* Index Name      Table Name      */  | 
3073  |  | #define SQLITE_CREATE_TABLE          2   /* Table Name      NULL            */  | 
3074  |  | #define SQLITE_CREATE_TEMP_INDEX     3   /* Index Name      Table Name      */  | 
3075  |  | #define SQLITE_CREATE_TEMP_TABLE     4   /* Table Name      NULL            */  | 
3076  |  | #define SQLITE_CREATE_TEMP_TRIGGER   5   /* Trigger Name    Table Name      */  | 
3077  |  | #define SQLITE_CREATE_TEMP_VIEW      6   /* View Name       NULL            */  | 
3078  |  | #define SQLITE_CREATE_TRIGGER        7   /* Trigger Name    Table Name      */  | 
3079  |  | #define SQLITE_CREATE_VIEW           8   /* View Name       NULL            */  | 
3080  |  | #define SQLITE_DELETE                9   /* Table Name      NULL            */  | 
3081  |  | #define SQLITE_DROP_INDEX           10   /* Index Name      Table Name      */  | 
3082  |  | #define SQLITE_DROP_TABLE           11   /* Table Name      NULL            */  | 
3083  |  | #define SQLITE_DROP_TEMP_INDEX      12   /* Index Name      Table Name      */  | 
3084  |  | #define SQLITE_DROP_TEMP_TABLE      13   /* Table Name      NULL            */  | 
3085  |  | #define SQLITE_DROP_TEMP_TRIGGER    14   /* Trigger Name    Table Name      */  | 
3086  |  | #define SQLITE_DROP_TEMP_VIEW       15   /* View Name       NULL            */  | 
3087  |  | #define SQLITE_DROP_TRIGGER         16   /* Trigger Name    Table Name      */  | 
3088  |  | #define SQLITE_DROP_VIEW            17   /* View Name       NULL            */  | 
3089  |  | #define SQLITE_INSERT               18   /* Table Name      NULL            */  | 
3090  | 270k  | #define SQLITE_PRAGMA               19   /* Pragma Name     1st arg or NULL */  | 
3091  |  | #define SQLITE_READ                 20   /* Table Name      Column Name     */  | 
3092  |  | #define SQLITE_SELECT               21   /* NULL            NULL            */  | 
3093  |  | #define SQLITE_TRANSACTION          22   /* Operation       NULL            */  | 
3094  |  | #define SQLITE_UPDATE               23   /* Table Name      Column Name     */  | 
3095  |  | #define SQLITE_ATTACH               24   /* Filename        NULL            */  | 
3096  |  | #define SQLITE_DETACH               25   /* Database Name   NULL            */  | 
3097  |  | #define SQLITE_ALTER_TABLE          26   /* Database Name   Table Name      */  | 
3098  |  | #define SQLITE_REINDEX              27   /* Index Name      NULL            */  | 
3099  |  | #define SQLITE_ANALYZE              28   /* Table Name      NULL            */  | 
3100  |  | #define SQLITE_CREATE_VTABLE        29   /* Table Name      Module Name     */  | 
3101  |  | #define SQLITE_DROP_VTABLE          30   /* Table Name      Module Name     */  | 
3102  |  | #define SQLITE_FUNCTION             31   /* NULL            Function Name   */  | 
3103  |  | #define SQLITE_SAVEPOINT            32   /* Operation       Savepoint Name  */  | 
3104  |  | #define SQLITE_COPY                  0   /* No longer used */  | 
3105  |  | #define SQLITE_RECURSIVE            33   /* NULL            NULL            */  | 
3106  |  |  | 
3107  |  | /*  | 
3108  |  | ** CAPI3REF: Tracing And Profiling Functions  | 
3109  |  | ** METHOD: sqlite3  | 
3110  |  | **  | 
3111  |  | ** These routines are deprecated. Use the [sqlite3_trace_v2()] interface  | 
3112  |  | ** instead of the routines described here.  | 
3113  |  | **  | 
3114  |  | ** These routines register callback functions that can be used for  | 
3115  |  | ** tracing and profiling the execution of SQL statements.  | 
3116  |  | **  | 
3117  |  | ** ^The callback function registered by sqlite3_trace() is invoked at  | 
3118  |  | ** various times when an SQL statement is being run by [sqlite3_step()].  | 
3119  |  | ** ^The sqlite3_trace() callback is invoked with a UTF-8 rendering of the  | 
3120  |  | ** SQL statement text as the statement first begins executing.  | 
3121  |  | ** ^(Additional sqlite3_trace() callbacks might occur  | 
3122  |  | ** as each triggered subprogram is entered.  The callbacks for triggers  | 
3123  |  | ** contain a UTF-8 SQL comment that identifies the trigger.)^  | 
3124  |  | **  | 
3125  |  | ** The [SQLITE_TRACE_SIZE_LIMIT] compile-time option can be used to limit  | 
3126  |  | ** the length of [bound parameter] expansion in the output of sqlite3_trace().  | 
3127  |  | **  | 
3128  |  | ** ^The callback function registered by sqlite3_profile() is invoked  | 
3129  |  | ** as each SQL statement finishes.  ^The profile callback contains  | 
3130  |  | ** the original statement text and an estimate of wall-clock time  | 
3131  |  | ** of how long that statement took to run.  ^The profile callback  | 
3132  |  | ** time is in units of nanoseconds, however the current implementation  | 
3133  |  | ** is only capable of millisecond resolution so the six least significant  | 
3134  |  | ** digits in the time are meaningless.  Future versions of SQLite  | 
3135  |  | ** might provide greater resolution on the profiler callback.  Invoking  | 
3136  |  | ** either [sqlite3_trace()] or [sqlite3_trace_v2()] will cancel the  | 
3137  |  | ** profile callback.  | 
3138  |  | */  | 
3139  |  | SQLITE_API SQLITE_DEPRECATED void *sqlite3_trace(sqlite3*,  | 
3140  |  |    void(*xTrace)(void*,const char*), void*);  | 
3141  |  | SQLITE_API SQLITE_DEPRECATED void *sqlite3_profile(sqlite3*,  | 
3142  |  |    void(*xProfile)(void*,const char*,sqlite3_uint64), void*);  | 
3143  |  |  | 
3144  |  | /*  | 
3145  |  | ** CAPI3REF: SQL Trace Event Codes  | 
3146  |  | ** KEYWORDS: SQLITE_TRACE  | 
3147  |  | **  | 
3148  |  | ** These constants identify classes of events that can be monitored  | 
3149  |  | ** using the [sqlite3_trace_v2()] tracing logic.  The M argument  | 
3150  |  | ** to [sqlite3_trace_v2(D,M,X,P)] is an OR-ed combination of one or more of  | 
3151  |  | ** the following constants.  ^The first argument to the trace callback  | 
3152  |  | ** is one of the following constants.  | 
3153  |  | **  | 
3154  |  | ** New tracing constants may be added in future releases.  | 
3155  |  | **  | 
3156  |  | ** ^A trace callback has four arguments: xCallback(T,C,P,X).  | 
3157  |  | ** ^The T argument is one of the integer type codes above.  | 
3158  |  | ** ^The C argument is a copy of the context pointer passed in as the  | 
3159  |  | ** fourth argument to [sqlite3_trace_v2()].  | 
3160  |  | ** The P and X arguments are pointers whose meanings depend on T.  | 
3161  |  | **  | 
3162  |  | ** <dl>  | 
3163  |  | ** [[SQLITE_TRACE_STMT]] <dt>SQLITE_TRACE_STMT</dt>  | 
3164  |  | ** <dd>^An SQLITE_TRACE_STMT callback is invoked when a prepared statement  | 
3165  |  | ** first begins running and possibly at other times during the  | 
3166  |  | ** execution of the prepared statement, such as at the start of each  | 
3167  |  | ** trigger subprogram. ^The P argument is a pointer to the  | 
3168  |  | ** [prepared statement]. ^The X argument is a pointer to a string which  | 
3169  |  | ** is the unexpanded SQL text of the prepared statement or an SQL comment  | 
3170  |  | ** that indicates the invocation of a trigger.  ^The callback can compute  | 
3171  |  | ** the same text that would have been returned by the legacy [sqlite3_trace()]  | 
3172  |  | ** interface by using the X argument when X begins with "--" and invoking  | 
3173  |  | ** [sqlite3_expanded_sql(P)] otherwise.  | 
3174  |  | **  | 
3175  |  | ** [[SQLITE_TRACE_PROFILE]] <dt>SQLITE_TRACE_PROFILE</dt>  | 
3176  |  | ** <dd>^An SQLITE_TRACE_PROFILE callback provides approximately the same  | 
3177  |  | ** information as is provided by the [sqlite3_profile()] callback.  | 
3178  |  | ** ^The P argument is a pointer to the [prepared statement] and the  | 
3179  |  | ** X argument points to a 64-bit integer which is the estimated of  | 
3180  |  | ** the number of nanosecond that the prepared statement took to run.  | 
3181  |  | ** ^The SQLITE_TRACE_PROFILE callback is invoked when the statement finishes.  | 
3182  |  | **  | 
3183  |  | ** [[SQLITE_TRACE_ROW]] <dt>SQLITE_TRACE_ROW</dt>  | 
3184  |  | ** <dd>^An SQLITE_TRACE_ROW callback is invoked whenever a prepared  | 
3185  |  | ** statement generates a single row of result.  | 
3186  |  | ** ^The P argument is a pointer to the [prepared statement] and the  | 
3187  |  | ** X argument is unused.  | 
3188  |  | **  | 
3189  |  | ** [[SQLITE_TRACE_CLOSE]] <dt>SQLITE_TRACE_CLOSE</dt>  | 
3190  |  | ** <dd>^An SQLITE_TRACE_CLOSE callback is invoked when a database  | 
3191  |  | ** connection closes.  | 
3192  |  | ** ^The P argument is a pointer to the [database connection] object  | 
3193  |  | ** and the X argument is unused.  | 
3194  |  | ** </dl>  | 
3195  |  | */  | 
3196  |  | #define SQLITE_TRACE_STMT       0x01  | 
3197  |  | #define SQLITE_TRACE_PROFILE    0x02  | 
3198  |  | #define SQLITE_TRACE_ROW        0x04  | 
3199  |  | #define SQLITE_TRACE_CLOSE      0x08  | 
3200  |  |  | 
3201  |  | /*  | 
3202  |  | ** CAPI3REF: SQL Trace Hook  | 
3203  |  | ** METHOD: sqlite3  | 
3204  |  | **  | 
3205  |  | ** ^The sqlite3_trace_v2(D,M,X,P) interface registers a trace callback  | 
3206  |  | ** function X against [database connection] D, using property mask M  | 
3207  |  | ** and context pointer P.  ^If the X callback is  | 
3208  |  | ** NULL or if the M mask is zero, then tracing is disabled.  The  | 
3209  |  | ** M argument should be the bitwise OR-ed combination of  | 
3210  |  | ** zero or more [SQLITE_TRACE] constants.  | 
3211  |  | **  | 
3212  |  | ** ^Each call to either sqlite3_trace() or sqlite3_trace_v2() overrides  | 
3213  |  | ** (cancels) any prior calls to sqlite3_trace() or sqlite3_trace_v2().  | 
3214  |  | **  | 
3215  |  | ** ^The X callback is invoked whenever any of the events identified by  | 
3216  |  | ** mask M occur.  ^The integer return value from the callback is currently  | 
3217  |  | ** ignored, though this may change in future releases.  Callback  | 
3218  |  | ** implementations should return zero to ensure future compatibility.  | 
3219  |  | **  | 
3220  |  | ** ^A trace callback is invoked with four arguments: callback(T,C,P,X).  | 
3221  |  | ** ^The T argument is one of the [SQLITE_TRACE]  | 
3222  |  | ** constants to indicate why the callback was invoked.  | 
3223  |  | ** ^The C argument is a copy of the context pointer.  | 
3224  |  | ** The P and X arguments are pointers whose meanings depend on T.  | 
3225  |  | **  | 
3226  |  | ** The sqlite3_trace_v2() interface is intended to replace the legacy  | 
3227  |  | ** interfaces [sqlite3_trace()] and [sqlite3_profile()], both of which  | 
3228  |  | ** are deprecated.  | 
3229  |  | */  | 
3230  |  | SQLITE_API int sqlite3_trace_v2(  | 
3231  |  |   sqlite3*,  | 
3232  |  |   unsigned uMask,  | 
3233  |  |   int(*xCallback)(unsigned,void*,void*,void*),  | 
3234  |  |   void *pCtx  | 
3235  |  | );  | 
3236  |  |  | 
3237  |  | /*  | 
3238  |  | ** CAPI3REF: Query Progress Callbacks  | 
3239  |  | ** METHOD: sqlite3  | 
3240  |  | **  | 
3241  |  | ** ^The sqlite3_progress_handler(D,N,X,P) interface causes the callback  | 
3242  |  | ** function X to be invoked periodically during long running calls to  | 
3243  |  | ** [sqlite3_exec()], [sqlite3_step()] and [sqlite3_get_table()] for  | 
3244  |  | ** database connection D.  An example use for this  | 
3245  |  | ** interface is to keep a GUI updated during a large query.  | 
3246  |  | **  | 
3247  |  | ** ^The parameter P is passed through as the only parameter to the  | 
3248  |  | ** callback function X.  ^The parameter N is the approximate number of  | 
3249  |  | ** [virtual machine instructions] that are evaluated between successive  | 
3250  |  | ** invocations of the callback X.  ^If N is less than one then the progress  | 
3251  |  | ** handler is disabled.  | 
3252  |  | **  | 
3253  |  | ** ^Only a single progress handler may be defined at one time per  | 
3254  |  | ** [database connection]; setting a new progress handler cancels the  | 
3255  |  | ** old one.  ^Setting parameter X to NULL disables the progress handler.  | 
3256  |  | ** ^The progress handler is also disabled by setting N to a value less  | 
3257  |  | ** than 1.  | 
3258  |  | **  | 
3259  |  | ** ^If the progress callback returns non-zero, the operation is  | 
3260  |  | ** interrupted.  This feature can be used to implement a  | 
3261  |  | ** "Cancel" button on a GUI progress dialog box.  | 
3262  |  | **  | 
3263  |  | ** The progress handler callback must not do anything that will modify  | 
3264  |  | ** the database connection that invoked the progress handler.  | 
3265  |  | ** Note that [sqlite3_prepare_v2()] and [sqlite3_step()] both modify their  | 
3266  |  | ** database connections for the meaning of "modify" in this paragraph.  | 
3267  |  | **  | 
3268  |  | */  | 
3269  |  | SQLITE_API void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);  | 
3270  |  |  | 
3271  |  | /*  | 
3272  |  | ** CAPI3REF: Opening A New Database Connection  | 
3273  |  | ** CONSTRUCTOR: sqlite3  | 
3274  |  | **  | 
3275  |  | ** ^These routines open an SQLite database file as specified by the  | 
3276  |  | ** filename argument. ^The filename argument is interpreted as UTF-8 for  | 
3277  |  | ** sqlite3_open() and sqlite3_open_v2() and as UTF-16 in the native byte  | 
3278  |  | ** order for sqlite3_open16(). ^(A [database connection] handle is usually  | 
3279  |  | ** returned in *ppDb, even if an error occurs.  The only exception is that  | 
3280  |  | ** if SQLite is unable to allocate memory to hold the [sqlite3] object,  | 
3281  |  | ** a NULL will be written into *ppDb instead of a pointer to the [sqlite3]  | 
3282  |  | ** object.)^ ^(If the database is opened (and/or created) successfully, then  | 
3283  |  | ** [SQLITE_OK] is returned.  Otherwise an [error code] is returned.)^ ^The  | 
3284  |  | ** [sqlite3_errmsg()] or [sqlite3_errmsg16()] routines can be used to obtain  | 
3285  |  | ** an English language description of the error following a failure of any  | 
3286  |  | ** of the sqlite3_open() routines.  | 
3287  |  | **  | 
3288  |  | ** ^The default encoding will be UTF-8 for databases created using  | 
3289  |  | ** sqlite3_open() or sqlite3_open_v2().  ^The default encoding for databases  | 
3290  |  | ** created using sqlite3_open16() will be UTF-16 in the native byte order.  | 
3291  |  | **  | 
3292  |  | ** Whether or not an error occurs when it is opened, resources  | 
3293  |  | ** associated with the [database connection] handle should be released by  | 
3294  |  | ** passing it to [sqlite3_close()] when it is no longer required.  | 
3295  |  | **  | 
3296  |  | ** The sqlite3_open_v2() interface works like sqlite3_open()  | 
3297  |  | ** except that it accepts two additional parameters for additional control  | 
3298  |  | ** over the new database connection.  ^(The flags parameter to  | 
3299  |  | ** sqlite3_open_v2() must include, at a minimum, one of the following  | 
3300  |  | ** three flag combinations:)^  | 
3301  |  | **  | 
3302  |  | ** <dl>  | 
3303  |  | ** ^(<dt>[SQLITE_OPEN_READONLY]</dt>  | 
3304  |  | ** <dd>The database is opened in read-only mode.  If the database does not  | 
3305  |  | ** already exist, an error is returned.</dd>)^  | 
3306  |  | **  | 
3307  |  | ** ^(<dt>[SQLITE_OPEN_READWRITE]</dt>  | 
3308  |  | ** <dd>The database is opened for reading and writing if possible, or reading  | 
3309  |  | ** only if the file is write protected by the operating system.  In either  | 
3310  |  | ** case the database must already exist, otherwise an error is returned.</dd>)^  | 
3311  |  | **  | 
3312  |  | ** ^(<dt>[SQLITE_OPEN_READWRITE] | [SQLITE_OPEN_CREATE]</dt>  | 
3313  |  | ** <dd>The database is opened for reading and writing, and is created if  | 
3314  |  | ** it does not already exist. This is the behavior that is always used for  | 
3315  |  | ** sqlite3_open() and sqlite3_open16().</dd>)^  | 
3316  |  | ** </dl>  | 
3317  |  | **  | 
3318  |  | ** In addition to the required flags, the following optional flags are  | 
3319  |  | ** also supported:  | 
3320  |  | **  | 
3321  |  | ** <dl>  | 
3322  |  | ** ^(<dt>[SQLITE_OPEN_URI]</dt>  | 
3323  |  | ** <dd>The filename can be interpreted as a URI if this flag is set.</dd>)^  | 
3324  |  | **  | 
3325  |  | ** ^(<dt>[SQLITE_OPEN_MEMORY]</dt>  | 
3326  |  | ** <dd>The database will be opened as an in-memory database.  The database  | 
3327  |  | ** is named by the "filename" argument for the purposes of cache-sharing,  | 
3328  |  | ** if shared cache mode is enabled, but the "filename" is otherwise ignored.  | 
3329  |  | ** </dd>)^  | 
3330  |  | **  | 
3331  |  | ** ^(<dt>[SQLITE_OPEN_NOMUTEX]</dt>  | 
3332  |  | ** <dd>The new database connection will use the "multi-thread"  | 
3333  |  | ** [threading mode].)^  This means that separate threads are allowed  | 
3334  |  | ** to use SQLite at the same time, as long as each thread is using  | 
3335  |  | ** a different [database connection].  | 
3336  |  | **  | 
3337  |  | ** ^(<dt>[SQLITE_OPEN_FULLMUTEX]</dt>  | 
3338  |  | ** <dd>The new database connection will use the "serialized"  | 
3339  |  | ** [threading mode].)^  This means the multiple threads can safely  | 
3340  |  | ** attempt to use the same database connection at the same time.  | 
3341  |  | ** (Mutexes will block any actual concurrency, but in this mode  | 
3342  |  | ** there is no harm in trying.)  | 
3343  |  | **  | 
3344  |  | ** ^(<dt>[SQLITE_OPEN_SHAREDCACHE]</dt>  | 
3345  |  | ** <dd>The database is opened [shared cache] enabled, overriding  | 
3346  |  | ** the default shared cache setting provided by  | 
3347  |  | ** [sqlite3_enable_shared_cache()].)^  | 
3348  |  | **  | 
3349  |  | ** ^(<dt>[SQLITE_OPEN_PRIVATECACHE]</dt>  | 
3350  |  | ** <dd>The database is opened [shared cache] disabled, overriding  | 
3351  |  | ** the default shared cache setting provided by  | 
3352  |  | ** [sqlite3_enable_shared_cache()].)^  | 
3353  |  | **  | 
3354  |  | ** [[OPEN_NOFOLLOW]] ^(<dt>[SQLITE_OPEN_NOFOLLOW]</dt>  | 
3355  |  | ** <dd>The database filename is not allowed to be a symbolic link</dd>  | 
3356  |  | ** </dl>)^  | 
3357  |  | **  | 
3358  |  | ** If the 3rd parameter to sqlite3_open_v2() is not one of the  | 
3359  |  | ** required combinations shown above optionally combined with other  | 
3360  |  | ** [SQLITE_OPEN_READONLY | SQLITE_OPEN_* bits]  | 
3361  |  | ** then the behavior is undefined.  | 
3362  |  | **  | 
3363  |  | ** ^The fourth parameter to sqlite3_open_v2() is the name of the  | 
3364  |  | ** [sqlite3_vfs] object that defines the operating system interface that  | 
3365  |  | ** the new database connection should use.  ^If the fourth parameter is  | 
3366  |  | ** a NULL pointer then the default [sqlite3_vfs] object is used.  | 
3367  |  | **  | 
3368  |  | ** ^If the filename is ":memory:", then a private, temporary in-memory database  | 
3369  |  | ** is created for the connection.  ^This in-memory database will vanish when  | 
3370  |  | ** the database connection is closed.  Future versions of SQLite might  | 
3371  |  | ** make use of additional special filenames that begin with the ":" character.  | 
3372  |  | ** It is recommended that when a database filename actually does begin with  | 
3373  |  | ** a ":" character you should prefix the filename with a pathname such as  | 
3374  |  | ** "./" to avoid ambiguity.  | 
3375  |  | **  | 
3376  |  | ** ^If the filename is an empty string, then a private, temporary  | 
3377  |  | ** on-disk database will be created.  ^This private database will be  | 
3378  |  | ** automatically deleted as soon as the database connection is closed.  | 
3379  |  | **  | 
3380  |  | ** [[URI filenames in sqlite3_open()]] <h3>URI Filenames</h3>  | 
3381  |  | **  | 
3382  |  | ** ^If [URI filename] interpretation is enabled, and the filename argument  | 
3383  |  | ** begins with "file:", then the filename is interpreted as a URI. ^URI  | 
3384  |  | ** filename interpretation is enabled if the [SQLITE_OPEN_URI] flag is  | 
3385  |  | ** set in the third argument to sqlite3_open_v2(), or if it has  | 
3386  |  | ** been enabled globally using the [SQLITE_CONFIG_URI] option with the  | 
3387  |  | ** [sqlite3_config()] method or by the [SQLITE_USE_URI] compile-time option.  | 
3388  |  | ** URI filename interpretation is turned off  | 
3389  |  | ** by default, but future releases of SQLite might enable URI filename  | 
3390  |  | ** interpretation by default.  See "[URI filenames]" for additional  | 
3391  |  | ** information.  | 
3392  |  | **  | 
3393  |  | ** URI filenames are parsed according to RFC 3986. ^If the URI contains an  | 
3394  |  | ** authority, then it must be either an empty string or the string  | 
3395  |  | ** "localhost". ^If the authority is not an empty string or "localhost", an  | 
3396  |  | ** error is returned to the caller. ^The fragment component of a URI, if  | 
3397  |  | ** present, is ignored.  | 
3398  |  | **  | 
3399  |  | ** ^SQLite uses the path component of the URI as the name of the disk file  | 
3400  |  | ** which contains the database. ^If the path begins with a '/' character,  | 
3401  |  | ** then it is interpreted as an absolute path. ^If the path does not begin  | 
3402  |  | ** with a '/' (meaning that the authority section is omitted from the URI)  | 
3403  |  | ** then the path is interpreted as a relative path.  | 
3404  |  | ** ^(On windows, the first component of an absolute path  | 
3405  |  | ** is a drive specification (e.g. "C:").)^  | 
3406  |  | **  | 
3407  |  | ** [[core URI query parameters]]  | 
3408  |  | ** The query component of a URI may contain parameters that are interpreted  | 
3409  |  | ** either by SQLite itself, or by a [VFS | custom VFS implementation].  | 
3410  |  | ** SQLite and its built-in [VFSes] interpret the  | 
3411  |  | ** following query parameters:  | 
3412  |  | **  | 
3413  |  | ** <ul>  | 
3414  |  | **   <li> <b>vfs</b>: ^The "vfs" parameter may be used to specify the name of  | 
3415  |  | **     a VFS object that provides the operating system interface that should  | 
3416  |  | **     be used to access the database file on disk. ^If this option is set to  | 
3417  |  | **     an empty string the default VFS object is used. ^Specifying an unknown  | 
3418  |  | **     VFS is an error. ^If sqlite3_open_v2() is used and the vfs option is  | 
3419  |  | **     present, then the VFS specified by the option takes precedence over  | 
3420  |  | **     the value passed as the fourth parameter to sqlite3_open_v2().  | 
3421  |  | **  | 
3422  |  | **   <li> <b>mode</b>: ^(The mode parameter may be set to either "ro", "rw",  | 
3423  |  | **     "rwc", or "memory". Attempting to set it to any other value is  | 
3424  |  | **     an error)^.  | 
3425  |  | **     ^If "ro" is specified, then the database is opened for read-only  | 
3426  |  | **     access, just as if the [SQLITE_OPEN_READONLY] flag had been set in the  | 
3427  |  | **     third argument to sqlite3_open_v2(). ^If the mode option is set to  | 
3428  |  | **     "rw", then the database is opened for read-write (but not create)  | 
3429  |  | **     access, as if SQLITE_OPEN_READWRITE (but not SQLITE_OPEN_CREATE) had  | 
3430  |  | **     been set. ^Value "rwc" is equivalent to setting both  | 
3431  |  | **     SQLITE_OPEN_READWRITE and SQLITE_OPEN_CREATE.  ^If the mode option is  | 
3432  |  | **     set to "memory" then a pure [in-memory database] that never reads  | 
3433  |  | **     or writes from disk is used. ^It is an error to specify a value for  | 
3434  |  | **     the mode parameter that is less restrictive than that specified by  | 
3435  |  | **     the flags passed in the third parameter to sqlite3_open_v2().  | 
3436  |  | **  | 
3437  |  | **   <li> <b>cache</b>: ^The cache parameter may be set to either "shared" or  | 
3438  |  | **     "private". ^Setting it to "shared" is equivalent to setting the  | 
3439  |  | **     SQLITE_OPEN_SHAREDCACHE bit in the flags argument passed to  | 
3440  |  | **     sqlite3_open_v2(). ^Setting the cache parameter to "private" is  | 
3441  |  | **     equivalent to setting the SQLITE_OPEN_PRIVATECACHE bit.  | 
3442  |  | **     ^If sqlite3_open_v2() is used and the "cache" parameter is present in  | 
3443  |  | **     a URI filename, its value overrides any behavior requested by setting  | 
3444  |  | **     SQLITE_OPEN_PRIVATECACHE or SQLITE_OPEN_SHAREDCACHE flag.  | 
3445  |  | **  | 
3446  |  | **  <li> <b>psow</b>: ^The psow parameter indicates whether or not the  | 
3447  |  | **     [powersafe overwrite] property does or does not apply to the  | 
3448  |  | **     storage media on which the database file resides.  | 
3449  |  | **  | 
3450  |  | **  <li> <b>nolock</b>: ^The nolock parameter is a boolean query parameter  | 
3451  |  | **     which if set disables file locking in rollback journal modes.  This  | 
3452  |  | **     is useful for accessing a database on a filesystem that does not  | 
3453  |  | **     support locking.  Caution:  Database corruption might result if two  | 
3454  |  | **     or more processes write to the same database and any one of those  | 
3455  |  | **     processes uses nolock=1.  | 
3456  |  | **  | 
3457  |  | **  <li> <b>immutable</b>: ^The immutable parameter is a boolean query  | 
3458  |  | **     parameter that indicates that the database file is stored on  | 
3459  |  | **     read-only media.  ^When immutable is set, SQLite assumes that the  | 
3460  |  | **     database file cannot be changed, even by a process with higher  | 
3461  |  | **     privilege, and so the database is opened read-only and all locking  | 
3462  |  | **     and change detection is disabled.  Caution: Setting the immutable  | 
3463  |  | **     property on a database file that does in fact change can result  | 
3464  |  | **     in incorrect query results and/or [SQLITE_CORRUPT] errors.  | 
3465  |  | **     See also: [SQLITE_IOCAP_IMMUTABLE].  | 
3466  |  | **  | 
3467  |  | ** </ul>  | 
3468  |  | **  | 
3469  |  | ** ^Specifying an unknown parameter in the query component of a URI is not an  | 
3470  |  | ** error.  Future versions of SQLite might understand additional query  | 
3471  |  | ** parameters.  See "[query parameters with special meaning to SQLite]" for  | 
3472  |  | ** additional information.  | 
3473  |  | **  | 
3474  |  | ** [[URI filename examples]] <h3>URI filename examples</h3>  | 
3475  |  | **  | 
3476  |  | ** <table border="1" align=center cellpadding=5>  | 
3477  |  | ** <tr><th> URI filenames <th> Results  | 
3478  |  | ** <tr><td> file:data.db <td>  | 
3479  |  | **          Open the file "data.db" in the current directory.  | 
3480  |  | ** <tr><td> file:/home/fred/data.db<br>  | 
3481  |  | **          file:///home/fred/data.db <br>  | 
3482  |  | **          file://localhost/home/fred/data.db <br> <td>  | 
3483  |  | **          Open the database file "/home/fred/data.db".  | 
3484  |  | ** <tr><td> file://darkstar/home/fred/data.db <td>  | 
3485  |  | **          An error. "darkstar" is not a recognized authority.  | 
3486  |  | ** <tr><td style="white-space:nowrap">  | 
3487  |  | **          file:///C:/Documents%20and%20Settings/fred/Desktop/data.db  | 
3488  |  | **     <td> Windows only: Open the file "data.db" on fred's desktop on drive  | 
3489  |  | **          C:. Note that the %20 escaping in this example is not strictly  | 
3490  |  | **          necessary - space characters can be used literally  | 
3491  |  | **          in URI filenames.  | 
3492  |  | ** <tr><td> file:data.db?mode=ro&cache=private <td>  | 
3493  |  | **          Open file "data.db" in the current directory for read-only access.  | 
3494  |  | **          Regardless of whether or not shared-cache mode is enabled by  | 
3495  |  | **          default, use a private cache.  | 
3496  |  | ** <tr><td> file:/home/fred/data.db?vfs=unix-dotfile <td>  | 
3497  |  | **          Open file "/home/fred/data.db". Use the special VFS "unix-dotfile"  | 
3498  |  | **          that uses dot-files in place of posix advisory locking.  | 
3499  |  | ** <tr><td> file:data.db?mode=readonly <td>  | 
3500  |  | **          An error. "readonly" is not a valid option for the "mode" parameter.  | 
3501  |  | ** </table>  | 
3502  |  | **  | 
3503  |  | ** ^URI hexadecimal escape sequences (%HH) are supported within the path and  | 
3504  |  | ** query components of a URI. A hexadecimal escape sequence consists of a  | 
3505  |  | ** percent sign - "%" - followed by exactly two hexadecimal digits  | 
3506  |  | ** specifying an octet value. ^Before the path or query components of a  | 
3507  |  | ** URI filename are interpreted, they are encoded using UTF-8 and all  | 
3508  |  | ** hexadecimal escape sequences replaced by a single byte containing the  | 
3509  |  | ** corresponding octet. If this process generates an invalid UTF-8 encoding,  | 
3510  |  | ** the results are undefined.  | 
3511  |  | **  | 
3512  |  | ** <b>Note to Windows users:</b>  The encoding used for the filename argument  | 
3513  |  | ** of sqlite3_open() and sqlite3_open_v2() must be UTF-8, not whatever  | 
3514  |  | ** codepage is currently defined.  Filenames containing international  | 
3515  |  | ** characters must be converted to UTF-8 prior to passing them into  | 
3516  |  | ** sqlite3_open() or sqlite3_open_v2().  | 
3517  |  | **  | 
3518  |  | ** <b>Note to Windows Runtime users:</b>  The temporary directory must be set  | 
3519  |  | ** prior to calling sqlite3_open() or sqlite3_open_v2().  Otherwise, various  | 
3520  |  | ** features that require the use of temporary files may fail.  | 
3521  |  | **  | 
3522  |  | ** See also: [sqlite3_temp_directory]  | 
3523  |  | */  | 
3524  |  | SQLITE_API int sqlite3_open(  | 
3525  |  |   const char *filename,   /* Database filename (UTF-8) */  | 
3526  |  |   sqlite3 **ppDb          /* OUT: SQLite db handle */  | 
3527  |  | );  | 
3528  |  | SQLITE_API int sqlite3_open16(  | 
3529  |  |   const void *filename,   /* Database filename (UTF-16) */  | 
3530  |  |   sqlite3 **ppDb          /* OUT: SQLite db handle */  | 
3531  |  | );  | 
3532  |  | SQLITE_API int sqlite3_open_v2(  | 
3533  |  |   const char *filename,   /* Database filename (UTF-8) */  | 
3534  |  |   sqlite3 **ppDb,         /* OUT: SQLite db handle */  | 
3535  |  |   int flags,              /* Flags */  | 
3536  |  |   const char *zVfs        /* Name of VFS module to use */  | 
3537  |  | );  | 
3538  |  |  | 
3539  |  | /*  | 
3540  |  | ** CAPI3REF: Obtain Values For URI Parameters  | 
3541  |  | **  | 
3542  |  | ** These are utility routines, useful to [VFS|custom VFS implementations],  | 
3543  |  | ** that check if a database file was a URI that contained a specific query  | 
3544  |  | ** parameter, and if so obtains the value of that query parameter.  | 
3545  |  | **  | 
3546  |  | ** The first parameter to these interfaces (hereafter referred to  | 
3547  |  | ** as F) must be one of:  | 
3548  |  | ** <ul>  | 
3549  |  | ** <li> A database filename pointer created by the SQLite core and  | 
3550  |  | ** passed into the xOpen() method of a VFS implemention, or  | 
3551  |  | ** <li> A filename obtained from [sqlite3_db_filename()], or  | 
3552  |  | ** <li> A new filename constructed using [sqlite3_create_filename()].  | 
3553  |  | ** </ul>  | 
3554  |  | ** If the F parameter is not one of the above, then the behavior is  | 
3555  |  | ** undefined and probably undesirable.  Older versions of SQLite were  | 
3556  |  | ** more tolerant of invalid F parameters than newer versions.  | 
3557  |  | **  | 
3558  |  | ** If F is a suitable filename (as described in the previous paragraph)  | 
3559  |  | ** and if P is the name of the query parameter, then  | 
3560  |  | ** sqlite3_uri_parameter(F,P) returns the value of the P  | 
3561  |  | ** parameter if it exists or a NULL pointer if P does not appear as a  | 
3562  |  | ** query parameter on F.  If P is a query parameter of F and it  | 
3563  |  | ** has no explicit value, then sqlite3_uri_parameter(F,P) returns  | 
3564  |  | ** a pointer to an empty string.  | 
3565  |  | **  | 
3566  |  | ** The sqlite3_uri_boolean(F,P,B) routine assumes that P is a boolean  | 
3567  |  | ** parameter and returns true (1) or false (0) according to the value  | 
3568  |  | ** of P.  The sqlite3_uri_boolean(F,P,B) routine returns true (1) if the  | 
3569  |  | ** value of query parameter P is one of "yes", "true", or "on" in any  | 
3570  |  | ** case or if the value begins with a non-zero number.  The  | 
3571  |  | ** sqlite3_uri_boolean(F,P,B) routines returns false (0) if the value of  | 
3572  |  | ** query parameter P is one of "no", "false", or "off" in any case or  | 
3573  |  | ** if the value begins with a numeric zero.  If P is not a query  | 
3574  |  | ** parameter on F or if the value of P does not match any of the  | 
3575  |  | ** above, then sqlite3_uri_boolean(F,P,B) returns (B!=0).  | 
3576  |  | **  | 
3577  |  | ** The sqlite3_uri_int64(F,P,D) routine converts the value of P into a  | 
3578  |  | ** 64-bit signed integer and returns that integer, or D if P does not  | 
3579  |  | ** exist.  If the value of P is something other than an integer, then  | 
3580  |  | ** zero is returned.  | 
3581  |  | **  | 
3582  |  | ** The sqlite3_uri_key(F,N) returns a pointer to the name (not  | 
3583  |  | ** the value) of the N-th query parameter for filename F, or a NULL  | 
3584  |  | ** pointer if N is less than zero or greater than the number of query  | 
3585  |  | ** parameters minus 1.  The N value is zero-based so N should be 0 to obtain  | 
3586  |  | ** the name of the first query parameter, 1 for the second parameter, and  | 
3587  |  | ** so forth.  | 
3588  |  | **  | 
3589  |  | ** If F is a NULL pointer, then sqlite3_uri_parameter(F,P) returns NULL and  | 
3590  |  | ** sqlite3_uri_boolean(F,P,B) returns B.  If F is not a NULL pointer and  | 
3591  |  | ** is not a database file pathname pointer that the SQLite core passed  | 
3592  |  | ** into the xOpen VFS method, then the behavior of this routine is undefined  | 
3593  |  | ** and probably undesirable.  | 
3594  |  | **  | 
3595  |  | ** Beginning with SQLite [version 3.31.0] ([dateof:3.31.0]) the input F  | 
3596  |  | ** parameter can also be the name of a rollback journal file or WAL file  | 
3597  |  | ** in addition to the main database file.  Prior to version 3.31.0, these  | 
3598  |  | ** routines would only work if F was the name of the main database file.  | 
3599  |  | ** When the F parameter is the name of the rollback journal or WAL file,  | 
3600  |  | ** it has access to all the same query parameters as were found on the  | 
3601  |  | ** main database file.  | 
3602  |  | **  | 
3603  |  | ** See the [URI filename] documentation for additional information.  | 
3604  |  | */  | 
3605  |  | SQLITE_API const char *sqlite3_uri_parameter(const char *zFilename, const char *zParam);  | 
3606  |  | SQLITE_API int sqlite3_uri_boolean(const char *zFile, const char *zParam, int bDefault);  | 
3607  |  | SQLITE_API sqlite3_int64 sqlite3_uri_int64(const char*, const char*, sqlite3_int64);  | 
3608  |  | SQLITE_API const char *sqlite3_uri_key(const char *zFilename, int N);  | 
3609  |  |  | 
3610  |  | /*  | 
3611  |  | ** CAPI3REF:  Translate filenames  | 
3612  |  | **  | 
3613  |  | ** These routines are available to [VFS|custom VFS implementations] for  | 
3614  |  | ** translating filenames between the main database file, the journal file,  | 
3615  |  | ** and the WAL file.  | 
3616  |  | **  | 
3617  |  | ** If F is the name of an sqlite database file, journal file, or WAL file  | 
3618  |  | ** passed by the SQLite core into the VFS, then sqlite3_filename_database(F)  | 
3619  |  | ** returns the name of the corresponding database file.  | 
3620  |  | **  | 
3621  |  | ** If F is the name of an sqlite database file, journal file, or WAL file  | 
3622  |  | ** passed by the SQLite core into the VFS, or if F is a database filename  | 
3623  |  | ** obtained from [sqlite3_db_filename()], then sqlite3_filename_journal(F)  | 
3624  |  | ** returns the name of the corresponding rollback journal file.  | 
3625  |  | **  | 
3626  |  | ** If F is the name of an sqlite database file, journal file, or WAL file  | 
3627  |  | ** that was passed by the SQLite core into the VFS, or if F is a database  | 
3628  |  | ** filename obtained from [sqlite3_db_filename()], then  | 
3629  |  | ** sqlite3_filename_wal(F) returns the name of the corresponding  | 
3630  |  | ** WAL file.  | 
3631  |  | **  | 
3632  |  | ** In all of the above, if F is not the name of a database, journal or WAL  | 
3633  |  | ** filename passed into the VFS from the SQLite core and F is not the  | 
3634  |  | ** return value from [sqlite3_db_filename()], then the result is  | 
3635  |  | ** undefined and is likely a memory access violation.  | 
3636  |  | */  | 
3637  |  | SQLITE_API const char *sqlite3_filename_database(const char*);  | 
3638  |  | SQLITE_API const char *sqlite3_filename_journal(const char*);  | 
3639  |  | SQLITE_API const char *sqlite3_filename_wal(const char*);  | 
3640  |  |  | 
3641  |  | /*  | 
3642  |  | ** CAPI3REF:  Database File Corresponding To A Journal  | 
3643  |  | **  | 
3644  |  | ** ^If X is the name of a rollback or WAL-mode journal file that is  | 
3645  |  | ** passed into the xOpen method of [sqlite3_vfs], then  | 
3646  |  | ** sqlite3_database_file_object(X) returns a pointer to the [sqlite3_file]  | 
3647  |  | ** object that represents the main database file.  | 
3648  |  | **  | 
3649  |  | ** This routine is intended for use in custom [VFS] implementations  | 
3650  |  | ** only.  It is not a general-purpose interface.  | 
3651  |  | ** The argument sqlite3_file_object(X) must be a filename pointer that  | 
3652  |  | ** has been passed into [sqlite3_vfs].xOpen method where the  | 
3653  |  | ** flags parameter to xOpen contains one of the bits  | 
3654  |  | ** [SQLITE_OPEN_MAIN_JOURNAL] or [SQLITE_OPEN_WAL].  Any other use  | 
3655  |  | ** of this routine results in undefined and probably undesirable  | 
3656  |  | ** behavior.  | 
3657  |  | */  | 
3658  |  | SQLITE_API sqlite3_file *sqlite3_database_file_object(const char*);  | 
3659  |  |  | 
3660  |  | /*  | 
3661  |  | ** CAPI3REF: Create and Destroy VFS Filenames  | 
3662  |  | **  | 
3663  |  | ** These interfces are provided for use by [VFS shim] implementations and  | 
3664  |  | ** are not useful outside of that context.  | 
3665  |  | **  | 
3666  |  | ** The sqlite3_create_filename(D,J,W,N,P) allocates memory to hold a version of  | 
3667  |  | ** database filename D with corresponding journal file J and WAL file W and  | 
3668  |  | ** with N URI parameters key/values pairs in the array P.  The result from  | 
3669  |  | ** sqlite3_create_filename(D,J,W,N,P) is a pointer to a database filename that  | 
3670  |  | ** is safe to pass to routines like:  | 
3671  |  | ** <ul>  | 
3672  |  | ** <li> [sqlite3_uri_parameter()],  | 
3673  |  | ** <li> [sqlite3_uri_boolean()],  | 
3674  |  | ** <li> [sqlite3_uri_int64()],  | 
3675  |  | ** <li> [sqlite3_uri_key()],  | 
3676  |  | ** <li> [sqlite3_filename_database()],  | 
3677  |  | ** <li> [sqlite3_filename_journal()], or  | 
3678  |  | ** <li> [sqlite3_filename_wal()].  | 
3679  |  | ** </ul>  | 
3680  |  | ** If a memory allocation error occurs, sqlite3_create_filename() might  | 
3681  |  | ** return a NULL pointer.  The memory obtained from sqlite3_create_filename(X)  | 
3682  |  | ** must be released by a corresponding call to sqlite3_free_filename(Y).  | 
3683  |  | **  | 
3684  |  | ** The P parameter in sqlite3_create_filename(D,J,W,N,P) should be an array  | 
3685  |  | ** of 2*N pointers to strings.  Each pair of pointers in this array corresponds  | 
3686  |  | ** to a key and value for a query parameter.  The P parameter may be a NULL  | 
3687  |  | ** pointer if N is zero.  None of the 2*N pointers in the P array may be  | 
3688  |  | ** NULL pointers and key pointers should not be empty strings.  | 
3689  |  | ** None of the D, J, or W parameters to sqlite3_create_filename(D,J,W,N,P) may  | 
3690  |  | ** be NULL pointers, though they can be empty strings.  | 
3691  |  | **  | 
3692  |  | ** The sqlite3_free_filename(Y) routine releases a memory allocation  | 
3693  |  | ** previously obtained from sqlite3_create_filename().  Invoking  | 
3694  |  | ** sqlite3_free_filename(Y) where Y is a NULL pointer is a harmless no-op.  | 
3695  |  | **  | 
3696  |  | ** If the Y parameter to sqlite3_free_filename(Y) is anything other  | 
3697  |  | ** than a NULL pointer or a pointer previously acquired from  | 
3698  |  | ** sqlite3_create_filename(), then bad things such as heap  | 
3699  |  | ** corruption or segfaults may occur. The value Y should be  | 
3700  |  | ** used again after sqlite3_free_filename(Y) has been called.  This means  | 
3701  |  | ** that if the [sqlite3_vfs.xOpen()] method of a VFS has been called using Y,  | 
3702  |  | ** then the corresponding [sqlite3_module.xClose() method should also be  | 
3703  |  | ** invoked prior to calling sqlite3_free_filename(Y).  | 
3704  |  | */  | 
3705  |  | SQLITE_API char *sqlite3_create_filename(  | 
3706  |  |   const char *zDatabase,  | 
3707  |  |   const char *zJournal,  | 
3708  |  |   const char *zWal,  | 
3709  |  |   int nParam,  | 
3710  |  |   const char **azParam  | 
3711  |  | );  | 
3712  |  | SQLITE_API void sqlite3_free_filename(char*);  | 
3713  |  |  | 
3714  |  | /*  | 
3715  |  | ** CAPI3REF: Error Codes And Messages  | 
3716  |  | ** METHOD: sqlite3  | 
3717  |  | **  | 
3718  |  | ** ^If the most recent sqlite3_* API call associated with  | 
3719  |  | ** [database connection] D failed, then the sqlite3_errcode(D) interface  | 
3720  |  | ** returns the numeric [result code] or [extended result code] for that  | 
3721  |  | ** API call.  | 
3722  |  | ** ^The sqlite3_extended_errcode()  | 
3723  |  | ** interface is the same except that it always returns the  | 
3724  |  | ** [extended result code] even when extended result codes are  | 
3725  |  | ** disabled.  | 
3726  |  | **  | 
3727  |  | ** The values returned by sqlite3_errcode() and/or  | 
3728  |  | ** sqlite3_extended_errcode() might change with each API call.  | 
3729  |  | ** Except, there are some interfaces that are guaranteed to never  | 
3730  |  | ** change the value of the error code.  The error-code preserving  | 
3731  |  | ** interfaces are:  | 
3732  |  | **  | 
3733  |  | ** <ul>  | 
3734  |  | ** <li> sqlite3_errcode()  | 
3735  |  | ** <li> sqlite3_extended_errcode()  | 
3736  |  | ** <li> sqlite3_errmsg()  | 
3737  |  | ** <li> sqlite3_errmsg16()  | 
3738  |  | ** </ul>  | 
3739  |  | **  | 
3740  |  | ** ^The sqlite3_errmsg() and sqlite3_errmsg16() return English-language  | 
3741  |  | ** text that describes the error, as either UTF-8 or UTF-16 respectively.  | 
3742  |  | ** ^(Memory to hold the error message string is managed internally.  | 
3743  |  | ** The application does not need to worry about freeing the result.  | 
3744  |  | ** However, the error string might be overwritten or deallocated by  | 
3745  |  | ** subsequent calls to other SQLite interface functions.)^  | 
3746  |  | **  | 
3747  |  | ** ^The sqlite3_errstr() interface returns the English-language text  | 
3748  |  | ** that describes the [result code], as UTF-8.  | 
3749  |  | ** ^(Memory to hold the error message string is managed internally  | 
3750  |  | ** and must not be freed by the application)^.  | 
3751  |  | **  | 
3752  |  | ** When the serialized [threading mode] is in use, it might be the  | 
3753  |  | ** case that a second error occurs on a separate thread in between  | 
3754  |  | ** the time of the first error and the call to these interfaces.  | 
3755  |  | ** When that happens, the second error will be reported since these  | 
3756  |  | ** interfaces always report the most recent result.  To avoid  | 
3757  |  | ** this, each thread can obtain exclusive use of the [database connection] D  | 
3758  |  | ** by invoking [sqlite3_mutex_enter]([sqlite3_db_mutex](D)) before beginning  | 
3759  |  | ** to use D and invoking [sqlite3_mutex_leave]([sqlite3_db_mutex](D)) after  | 
3760  |  | ** all calls to the interfaces listed here are completed.  | 
3761  |  | **  | 
3762  |  | ** If an interface fails with SQLITE_MISUSE, that means the interface  | 
3763  |  | ** was invoked incorrectly by the application.  In that case, the  | 
3764  |  | ** error code and message may or may not be set.  | 
3765  |  | */  | 
3766  |  | SQLITE_API int sqlite3_errcode(sqlite3 *db);  | 
3767  |  | SQLITE_API int sqlite3_extended_errcode(sqlite3 *db);  | 
3768  |  | SQLITE_API const char *sqlite3_errmsg(sqlite3*);  | 
3769  |  | SQLITE_API const void *sqlite3_errmsg16(sqlite3*);  | 
3770  |  | SQLITE_API const char *sqlite3_errstr(int);  | 
3771  |  |  | 
3772  |  | /*  | 
3773  |  | ** CAPI3REF: Prepared Statement Object  | 
3774  |  | ** KEYWORDS: {prepared statement} {prepared statements} | 
3775  |  | **  | 
3776  |  | ** An instance of this object represents a single SQL statement that  | 
3777  |  | ** has been compiled into binary form and is ready to be evaluated.  | 
3778  |  | **  | 
3779  |  | ** Think of each SQL statement as a separate computer program.  The  | 
3780  |  | ** original SQL text is source code.  A prepared statement object  | 
3781  |  | ** is the compiled object code.  All SQL must be converted into a  | 
3782  |  | ** prepared statement before it can be run.  | 
3783  |  | **  | 
3784  |  | ** The life-cycle of a prepared statement object usually goes like this:  | 
3785  |  | **  | 
3786  |  | ** <ol>  | 
3787  |  | ** <li> Create the prepared statement object using [sqlite3_prepare_v2()].  | 
3788  |  | ** <li> Bind values to [parameters] using the sqlite3_bind_*()  | 
3789  |  | **      interfaces.  | 
3790  |  | ** <li> Run the SQL by calling [sqlite3_step()] one or more times.  | 
3791  |  | ** <li> Reset the prepared statement using [sqlite3_reset()] then go back  | 
3792  |  | **      to step 2.  Do this zero or more times.  | 
3793  |  | ** <li> Destroy the object using [sqlite3_finalize()].  | 
3794  |  | ** </ol>  | 
3795  |  | */  | 
3796  |  | typedef struct sqlite3_stmt sqlite3_stmt;  | 
3797  |  |  | 
3798  |  | /*  | 
3799  |  | ** CAPI3REF: Run-time Limits  | 
3800  |  | ** METHOD: sqlite3  | 
3801  |  | **  | 
3802  |  | ** ^(This interface allows the size of various constructs to be limited  | 
3803  |  | ** on a connection by connection basis.  The first parameter is the  | 
3804  |  | ** [database connection] whose limit is to be set or queried.  The  | 
3805  |  | ** second parameter is one of the [limit categories] that define a  | 
3806  |  | ** class of constructs to be size limited.  The third parameter is the  | 
3807  |  | ** new limit for that construct.)^  | 
3808  |  | **  | 
3809  |  | ** ^If the new limit is a negative number, the limit is unchanged.  | 
3810  |  | ** ^(For each limit category SQLITE_LIMIT_<i>NAME</i> there is a  | 
3811  |  | ** [limits | hard upper bound]  | 
3812  |  | ** set at compile-time by a C preprocessor macro called  | 
3813  |  | ** [limits | SQLITE_MAX_<i>NAME</i>].  | 
3814  |  | ** (The "_LIMIT_" in the name is changed to "_MAX_".))^  | 
3815  |  | ** ^Attempts to increase a limit above its hard upper bound are  | 
3816  |  | ** silently truncated to the hard upper bound.  | 
3817  |  | **  | 
3818  |  | ** ^Regardless of whether or not the limit was changed, the  | 
3819  |  | ** [sqlite3_limit()] interface returns the prior value of the limit.  | 
3820  |  | ** ^Hence, to find the current value of a limit without changing it,  | 
3821  |  | ** simply invoke this interface with the third parameter set to -1.  | 
3822  |  | **  | 
3823  |  | ** Run-time limits are intended for use in applications that manage  | 
3824  |  | ** both their own internal database and also databases that are controlled  | 
3825  |  | ** by untrusted external sources.  An example application might be a  | 
3826  |  | ** web browser that has its own databases for storing history and  | 
3827  |  | ** separate databases controlled by JavaScript applications downloaded  | 
3828  |  | ** off the Internet.  The internal databases can be given the  | 
3829  |  | ** large, default limits.  Databases managed by external sources can  | 
3830  |  | ** be given much smaller limits designed to prevent a denial of service  | 
3831  |  | ** attack.  Developers might also want to use the [sqlite3_set_authorizer()]  | 
3832  |  | ** interface to further control untrusted SQL.  The size of the database  | 
3833  |  | ** created by an untrusted script can be contained using the  | 
3834  |  | ** [max_page_count] [PRAGMA].  | 
3835  |  | **  | 
3836  |  | ** New run-time limit categories may be added in future releases.  | 
3837  |  | */  | 
3838  |  | SQLITE_API int sqlite3_limit(sqlite3*, int id, int newVal);  | 
3839  |  |  | 
3840  |  | /*  | 
3841  |  | ** CAPI3REF: Run-Time Limit Categories  | 
3842  |  | ** KEYWORDS: {limit category} {*limit categories} | 
3843  |  | **  | 
3844  |  | ** These constants define various performance limits  | 
3845  |  | ** that can be lowered at run-time using [sqlite3_limit()].  | 
3846  |  | ** The synopsis of the meanings of the various limits is shown below.  | 
3847  |  | ** Additional information is available at [limits | Limits in SQLite].  | 
3848  |  | **  | 
3849  |  | ** <dl>  | 
3850  |  | ** [[SQLITE_LIMIT_LENGTH]] ^(<dt>SQLITE_LIMIT_LENGTH</dt>  | 
3851  |  | ** <dd>The maximum size of any string or BLOB or table row, in bytes.<dd>)^  | 
3852  |  | **  | 
3853  |  | ** [[SQLITE_LIMIT_SQL_LENGTH]] ^(<dt>SQLITE_LIMIT_SQL_LENGTH</dt>  | 
3854  |  | ** <dd>The maximum length of an SQL statement, in bytes.</dd>)^  | 
3855  |  | **  | 
3856  |  | ** [[SQLITE_LIMIT_COLUMN]] ^(<dt>SQLITE_LIMIT_COLUMN</dt>  | 
3857  |  | ** <dd>The maximum number of columns in a table definition or in the  | 
3858  |  | ** result set of a [SELECT] or the maximum number of columns in an index  | 
3859  |  | ** or in an ORDER BY or GROUP BY clause.</dd>)^  | 
3860  |  | **  | 
3861  |  | ** [[SQLITE_LIMIT_EXPR_DEPTH]] ^(<dt>SQLITE_LIMIT_EXPR_DEPTH</dt>  | 
3862  |  | ** <dd>The maximum depth of the parse tree on any expression.</dd>)^  | 
3863  |  | **  | 
3864  |  | ** [[SQLITE_LIMIT_COMPOUND_SELECT]] ^(<dt>SQLITE_LIMIT_COMPOUND_SELECT</dt>  | 
3865  |  | ** <dd>The maximum number of terms in a compound SELECT statement.</dd>)^  | 
3866  |  | **  | 
3867  |  | ** [[SQLITE_LIMIT_VDBE_OP]] ^(<dt>SQLITE_LIMIT_VDBE_OP</dt>  | 
3868  |  | ** <dd>The maximum number of instructions in a virtual machine program  | 
3869  |  | ** used to implement an SQL statement.  If [sqlite3_prepare_v2()] or  | 
3870  |  | ** the equivalent tries to allocate space for more than this many opcodes  | 
3871  |  | ** in a single prepared statement, an SQLITE_NOMEM error is returned.</dd>)^  | 
3872  |  | **  | 
3873  |  | ** [[SQLITE_LIMIT_FUNCTION_ARG]] ^(<dt>SQLITE_LIMIT_FUNCTION_ARG</dt>  | 
3874  |  | ** <dd>The maximum number of arguments on a function.</dd>)^  | 
3875  |  | **  | 
3876  |  | ** [[SQLITE_LIMIT_ATTACHED]] ^(<dt>SQLITE_LIMIT_ATTACHED</dt>  | 
3877  |  | ** <dd>The maximum number of [ATTACH | attached databases].)^</dd>  | 
3878  |  | **  | 
3879  |  | ** [[SQLITE_LIMIT_LIKE_PATTERN_LENGTH]]  | 
3880  |  | ** ^(<dt>SQLITE_LIMIT_LIKE_PATTERN_LENGTH</dt>  | 
3881  |  | ** <dd>The maximum length of the pattern argument to the [LIKE] or  | 
3882  |  | ** [GLOB] operators.</dd>)^  | 
3883  |  | **  | 
3884  |  | ** [[SQLITE_LIMIT_VARIABLE_NUMBER]]  | 
3885  |  | ** ^(<dt>SQLITE_LIMIT_VARIABLE_NUMBER</dt>  | 
3886  |  | ** <dd>The maximum index number of any [parameter] in an SQL statement.)^  | 
3887  |  | **  | 
3888  |  | ** [[SQLITE_LIMIT_TRIGGER_DEPTH]] ^(<dt>SQLITE_LIMIT_TRIGGER_DEPTH</dt>  | 
3889  |  | ** <dd>The maximum depth of recursion for triggers.</dd>)^  | 
3890  |  | **  | 
3891  |  | ** [[SQLITE_LIMIT_WORKER_THREADS]] ^(<dt>SQLITE_LIMIT_WORKER_THREADS</dt>  | 
3892  |  | ** <dd>The maximum number of auxiliary worker threads that a single  | 
3893  |  | ** [prepared statement] may start.</dd>)^  | 
3894  |  | ** </dl>  | 
3895  |  | */  | 
3896  | 20.2k  | #define SQLITE_LIMIT_LENGTH                    0  | 
3897  |  | #define SQLITE_LIMIT_SQL_LENGTH                1  | 
3898  |  | #define SQLITE_LIMIT_COLUMN                    2  | 
3899  |  | #define SQLITE_LIMIT_EXPR_DEPTH                3  | 
3900  |  | #define SQLITE_LIMIT_COMPOUND_SELECT           4  | 
3901  | 20.2k  | #define SQLITE_LIMIT_VDBE_OP                   5  | 
3902  |  | #define SQLITE_LIMIT_FUNCTION_ARG              6  | 
3903  |  | #define SQLITE_LIMIT_ATTACHED                  7  | 
3904  |  | #define SQLITE_LIMIT_LIKE_PATTERN_LENGTH       8  | 
3905  |  | #define SQLITE_LIMIT_VARIABLE_NUMBER           9  | 
3906  |  | #define SQLITE_LIMIT_TRIGGER_DEPTH            10  | 
3907  |  | #define SQLITE_LIMIT_WORKER_THREADS           11  | 
3908  |  |  | 
3909  |  | /*  | 
3910  |  | ** CAPI3REF: Prepare Flags  | 
3911  |  | **  | 
3912  |  | ** These constants define various flags that can be passed into  | 
3913  |  | ** "prepFlags" parameter of the [sqlite3_prepare_v3()] and  | 
3914  |  | ** [sqlite3_prepare16_v3()] interfaces.  | 
3915  |  | **  | 
3916  |  | ** New flags may be added in future releases of SQLite.  | 
3917  |  | **  | 
3918  |  | ** <dl>  | 
3919  |  | ** [[SQLITE_PREPARE_PERSISTENT]] ^(<dt>SQLITE_PREPARE_PERSISTENT</dt>  | 
3920  |  | ** <dd>The SQLITE_PREPARE_PERSISTENT flag is a hint to the query planner  | 
3921  |  | ** that the prepared statement will be retained for a long time and  | 
3922  |  | ** probably reused many times.)^ ^Without this flag, [sqlite3_prepare_v3()]  | 
3923  |  | ** and [sqlite3_prepare16_v3()] assume that the prepared statement will  | 
3924  |  | ** be used just once or at most a few times and then destroyed using  | 
3925  |  | ** [sqlite3_finalize()] relatively soon. The current implementation acts  | 
3926  |  | ** on this hint by avoiding the use of [lookaside memory] so as not to  | 
3927  |  | ** deplete the limited store of lookaside memory. Future versions of  | 
3928  |  | ** SQLite may act on this hint differently.  | 
3929  |  | **  | 
3930  |  | ** [[SQLITE_PREPARE_NORMALIZE]] <dt>SQLITE_PREPARE_NORMALIZE</dt>  | 
3931  |  | ** <dd>The SQLITE_PREPARE_NORMALIZE flag is a no-op. This flag used  | 
3932  |  | ** to be required for any prepared statement that wanted to use the  | 
3933  |  | ** [sqlite3_normalized_sql()] interface.  However, the  | 
3934  |  | ** [sqlite3_normalized_sql()] interface is now available to all  | 
3935  |  | ** prepared statements, regardless of whether or not they use this  | 
3936  |  | ** flag.  | 
3937  |  | **  | 
3938  |  | ** [[SQLITE_PREPARE_NO_VTAB]] <dt>SQLITE_PREPARE_NO_VTAB</dt>  | 
3939  |  | ** <dd>The SQLITE_PREPARE_NO_VTAB flag causes the SQL compiler  | 
3940  |  | ** to return an error (error code SQLITE_ERROR) if the statement uses  | 
3941  |  | ** any virtual tables.  | 
3942  |  | ** </dl>  | 
3943  |  | */  | 
3944  |  | #define SQLITE_PREPARE_PERSISTENT              0x01  | 
3945  |  | #define SQLITE_PREPARE_NORMALIZE               0x02  | 
3946  |  | #define SQLITE_PREPARE_NO_VTAB                 0x04  | 
3947  |  |  | 
3948  |  | /*  | 
3949  |  | ** CAPI3REF: Compiling An SQL Statement  | 
3950  |  | ** KEYWORDS: {SQL statement compiler} | 
3951  |  | ** METHOD: sqlite3  | 
3952  |  | ** CONSTRUCTOR: sqlite3_stmt  | 
3953  |  | **  | 
3954  |  | ** To execute an SQL statement, it must first be compiled into a byte-code  | 
3955  |  | ** program using one of these routines.  Or, in other words, these routines  | 
3956  |  | ** are constructors for the [prepared statement] object.  | 
3957  |  | **  | 
3958  |  | ** The preferred routine to use is [sqlite3_prepare_v2()].  The  | 
3959  |  | ** [sqlite3_prepare()] interface is legacy and should be avoided.  | 
3960  |  | ** [sqlite3_prepare_v3()] has an extra "prepFlags" option that is used  | 
3961  |  | ** for special purposes.  | 
3962  |  | **  | 
3963  |  | ** The use of the UTF-8 interfaces is preferred, as SQLite currently  | 
3964  |  | ** does all parsing using UTF-8.  The UTF-16 interfaces are provided  | 
3965  |  | ** as a convenience.  The UTF-16 interfaces work by converting the  | 
3966  |  | ** input text into UTF-8, then invoking the corresponding UTF-8 interface.  | 
3967  |  | **  | 
3968  |  | ** The first argument, "db", is a [database connection] obtained from a  | 
3969  |  | ** prior successful call to [sqlite3_open()], [sqlite3_open_v2()] or  | 
3970  |  | ** [sqlite3_open16()].  The database connection must not have been closed.  | 
3971  |  | **  | 
3972  |  | ** The second argument, "zSql", is the statement to be compiled, encoded  | 
3973  |  | ** as either UTF-8 or UTF-16.  The sqlite3_prepare(), sqlite3_prepare_v2(),  | 
3974  |  | ** and sqlite3_prepare_v3()  | 
3975  |  | ** interfaces use UTF-8, and sqlite3_prepare16(), sqlite3_prepare16_v2(),  | 
3976  |  | ** and sqlite3_prepare16_v3() use UTF-16.  | 
3977  |  | **  | 
3978  |  | ** ^If the nByte argument is negative, then zSql is read up to the  | 
3979  |  | ** first zero terminator. ^If nByte is positive, then it is the  | 
3980  |  | ** number of bytes read from zSql.  ^If nByte is zero, then no prepared  | 
3981  |  | ** statement is generated.  | 
3982  |  | ** If the caller knows that the supplied string is nul-terminated, then  | 
3983  |  | ** there is a small performance advantage to passing an nByte parameter that  | 
3984  |  | ** is the number of bytes in the input string <i>including</i>  | 
3985  |  | ** the nul-terminator.  | 
3986  |  | **  | 
3987  |  | ** ^If pzTail is not NULL then *pzTail is made to point to the first byte  | 
3988  |  | ** past the end of the first SQL statement in zSql.  These routines only  | 
3989  |  | ** compile the first statement in zSql, so *pzTail is left pointing to  | 
3990  |  | ** what remains uncompiled.  | 
3991  |  | **  | 
3992  |  | ** ^*ppStmt is left pointing to a compiled [prepared statement] that can be  | 
3993  |  | ** executed using [sqlite3_step()].  ^If there is an error, *ppStmt is set  | 
3994  |  | ** to NULL.  ^If the input text contains no SQL (if the input is an empty  | 
3995  |  | ** string or a comment) then *ppStmt is set to NULL.  | 
3996  |  | ** The calling procedure is responsible for deleting the compiled  | 
3997  |  | ** SQL statement using [sqlite3_finalize()] after it has finished with it.  | 
3998  |  | ** ppStmt may not be NULL.  | 
3999  |  | **  | 
4000  |  | ** ^On success, the sqlite3_prepare() family of routines return [SQLITE_OK];  | 
4001  |  | ** otherwise an [error code] is returned.  | 
4002  |  | **  | 
4003  |  | ** The sqlite3_prepare_v2(), sqlite3_prepare_v3(), sqlite3_prepare16_v2(),  | 
4004  |  | ** and sqlite3_prepare16_v3() interfaces are recommended for all new programs.  | 
4005  |  | ** The older interfaces (sqlite3_prepare() and sqlite3_prepare16())  | 
4006  |  | ** are retained for backwards compatibility, but their use is discouraged.  | 
4007  |  | ** ^In the "vX" interfaces, the prepared statement  | 
4008  |  | ** that is returned (the [sqlite3_stmt] object) contains a copy of the  | 
4009  |  | ** original SQL text. This causes the [sqlite3_step()] interface to  | 
4010  |  | ** behave differently in three ways:  | 
4011  |  | **  | 
4012  |  | ** <ol>  | 
4013  |  | ** <li>  | 
4014  |  | ** ^If the database schema changes, instead of returning [SQLITE_SCHEMA] as it  | 
4015  |  | ** always used to do, [sqlite3_step()] will automatically recompile the SQL  | 
4016  |  | ** statement and try to run it again. As many as [SQLITE_MAX_SCHEMA_RETRY]  | 
4017  |  | ** retries will occur before sqlite3_step() gives up and returns an error.  | 
4018  |  | ** </li>  | 
4019  |  | **  | 
4020  |  | ** <li>  | 
4021  |  | ** ^When an error occurs, [sqlite3_step()] will return one of the detailed  | 
4022  |  | ** [error codes] or [extended error codes].  ^The legacy behavior was that  | 
4023  |  | ** [sqlite3_step()] would only return a generic [SQLITE_ERROR] result code  | 
4024  |  | ** and the application would have to make a second call to [sqlite3_reset()]  | 
4025  |  | ** in order to find the underlying cause of the problem. With the "v2" prepare  | 
4026  |  | ** interfaces, the underlying reason for the error is returned immediately.  | 
4027  |  | ** </li>  | 
4028  |  | **  | 
4029  |  | ** <li>  | 
4030  |  | ** ^If the specific value bound to a [parameter | host parameter] in the  | 
4031  |  | ** WHERE clause might influence the choice of query plan for a statement,  | 
4032  |  | ** then the statement will be automatically recompiled, as if there had been  | 
4033  |  | ** a schema change, on the first [sqlite3_step()] call following any change  | 
4034  |  | ** to the [sqlite3_bind_text | bindings] of that [parameter].  | 
4035  |  | ** ^The specific value of a WHERE-clause [parameter] might influence the  | 
4036  |  | ** choice of query plan if the parameter is the left-hand side of a [LIKE]  | 
4037  |  | ** or [GLOB] operator or if the parameter is compared to an indexed column  | 
4038  |  | ** and the [SQLITE_ENABLE_STAT4] compile-time option is enabled.  | 
4039  |  | ** </li>  | 
4040  |  | ** </ol>  | 
4041  |  | **  | 
4042  |  | ** <p>^sqlite3_prepare_v3() differs from sqlite3_prepare_v2() only in having  | 
4043  |  | ** the extra prepFlags parameter, which is a bit array consisting of zero or  | 
4044  |  | ** more of the [SQLITE_PREPARE_PERSISTENT|SQLITE_PREPARE_*] flags.  ^The  | 
4045  |  | ** sqlite3_prepare_v2() interface works exactly the same as  | 
4046  |  | ** sqlite3_prepare_v3() with a zero prepFlags parameter.  | 
4047  |  | */  | 
4048  |  | SQLITE_API int sqlite3_prepare(  | 
4049  |  |   sqlite3 *db,            /* Database handle */  | 
4050  |  |   const char *zSql,       /* SQL statement, UTF-8 encoded */  | 
4051  |  |   int nByte,              /* Maximum length of zSql in bytes. */  | 
4052  |  |   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */  | 
4053  |  |   const char **pzTail     /* OUT: Pointer to unused portion of zSql */  | 
4054  |  | );  | 
4055  |  | SQLITE_API int sqlite3_prepare_v2(  | 
4056  |  |   sqlite3 *db,            /* Database handle */  | 
4057  |  |   const char *zSql,       /* SQL statement, UTF-8 encoded */  | 
4058  |  |   int nByte,              /* Maximum length of zSql in bytes. */  | 
4059  |  |   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */  | 
4060  |  |   const char **pzTail     /* OUT: Pointer to unused portion of zSql */  | 
4061  |  | );  | 
4062  |  | SQLITE_API int sqlite3_prepare_v3(  | 
4063  |  |   sqlite3 *db,            /* Database handle */  | 
4064  |  |   const char *zSql,       /* SQL statement, UTF-8 encoded */  | 
4065  |  |   int nByte,              /* Maximum length of zSql in bytes. */  | 
4066  |  |   unsigned int prepFlags, /* Zero or more SQLITE_PREPARE_ flags */  | 
4067  |  |   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */  | 
4068  |  |   const char **pzTail     /* OUT: Pointer to unused portion of zSql */  | 
4069  |  | );  | 
4070  |  | SQLITE_API int sqlite3_prepare16(  | 
4071  |  |   sqlite3 *db,            /* Database handle */  | 
4072  |  |   const void *zSql,       /* SQL statement, UTF-16 encoded */  | 
4073  |  |   int nByte,              /* Maximum length of zSql in bytes. */  | 
4074  |  |   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */  | 
4075  |  |   const void **pzTail     /* OUT: Pointer to unused portion of zSql */  | 
4076  |  | );  | 
4077  |  | SQLITE_API int sqlite3_prepare16_v2(  | 
4078  |  |   sqlite3 *db,            /* Database handle */  | 
4079  |  |   const void *zSql,       /* SQL statement, UTF-16 encoded */  | 
4080  |  |   int nByte,              /* Maximum length of zSql in bytes. */  | 
4081  |  |   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */  | 
4082  |  |   const void **pzTail     /* OUT: Pointer to unused portion of zSql */  | 
4083  |  | );  | 
4084  |  | SQLITE_API int sqlite3_prepare16_v3(  | 
4085  |  |   sqlite3 *db,            /* Database handle */  | 
4086  |  |   const void *zSql,       /* SQL statement, UTF-16 encoded */  | 
4087  |  |   int nByte,              /* Maximum length of zSql in bytes. */  | 
4088  |  |   unsigned int prepFlags, /* Zero or more SQLITE_PREPARE_ flags */  | 
4089  |  |   sqlite3_stmt **ppStmt,  /* OUT: Statement handle */  | 
4090  |  |   const void **pzTail     /* OUT: Pointer to unused portion of zSql */  | 
4091  |  | );  | 
4092  |  |  | 
4093  |  | /*  | 
4094  |  | ** CAPI3REF: Retrieving Statement SQL  | 
4095  |  | ** METHOD: sqlite3_stmt  | 
4096  |  | **  | 
4097  |  | ** ^The sqlite3_sql(P) interface returns a pointer to a copy of the UTF-8  | 
4098  |  | ** SQL text used to create [prepared statement] P if P was  | 
4099  |  | ** created by [sqlite3_prepare_v2()], [sqlite3_prepare_v3()],  | 
4100  |  | ** [sqlite3_prepare16_v2()], or [sqlite3_prepare16_v3()].  | 
4101  |  | ** ^The sqlite3_expanded_sql(P) interface returns a pointer to a UTF-8  | 
4102  |  | ** string containing the SQL text of prepared statement P with  | 
4103  |  | ** [bound parameters] expanded.  | 
4104  |  | ** ^The sqlite3_normalized_sql(P) interface returns a pointer to a UTF-8  | 
4105  |  | ** string containing the normalized SQL text of prepared statement P.  The  | 
4106  |  | ** semantics used to normalize a SQL statement are unspecified and subject  | 
4107  |  | ** to change.  At a minimum, literal values will be replaced with suitable  | 
4108  |  | ** placeholders.  | 
4109  |  | **  | 
4110  |  | ** ^(For example, if a prepared statement is created using the SQL  | 
4111  |  | ** text "SELECT $abc,:xyz" and if parameter $abc is bound to integer 2345  | 
4112  |  | ** and parameter :xyz is unbound, then sqlite3_sql() will return  | 
4113  |  | ** the original string, "SELECT $abc,:xyz" but sqlite3_expanded_sql()  | 
4114  |  | ** will return "SELECT 2345,NULL".)^  | 
4115  |  | **  | 
4116  |  | ** ^The sqlite3_expanded_sql() interface returns NULL if insufficient memory  | 
4117  |  | ** is available to hold the result, or if the result would exceed the  | 
4118  |  | ** the maximum string length determined by the [SQLITE_LIMIT_LENGTH].  | 
4119  |  | **  | 
4120  |  | ** ^The [SQLITE_TRACE_SIZE_LIMIT] compile-time option limits the size of  | 
4121  |  | ** bound parameter expansions.  ^The [SQLITE_OMIT_TRACE] compile-time  | 
4122  |  | ** option causes sqlite3_expanded_sql() to always return NULL.  | 
4123  |  | **  | 
4124  |  | ** ^The strings returned by sqlite3_sql(P) and sqlite3_normalized_sql(P)  | 
4125  |  | ** are managed by SQLite and are automatically freed when the prepared  | 
4126  |  | ** statement is finalized.  | 
4127  |  | ** ^The string returned by sqlite3_expanded_sql(P), on the other hand,  | 
4128  |  | ** is obtained from [sqlite3_malloc()] and must be free by the application  | 
4129  |  | ** by passing it to [sqlite3_free()].  | 
4130  |  | */  | 
4131  |  | SQLITE_API const char *sqlite3_sql(sqlite3_stmt *pStmt);  | 
4132  |  | SQLITE_API char *sqlite3_expanded_sql(sqlite3_stmt *pStmt);  | 
4133  |  | SQLITE_API const char *sqlite3_normalized_sql(sqlite3_stmt *pStmt);  | 
4134  |  |  | 
4135  |  | /*  | 
4136  |  | ** CAPI3REF: Determine If An SQL Statement Writes The Database  | 
4137  |  | ** METHOD: sqlite3_stmt  | 
4138  |  | **  | 
4139  |  | ** ^The sqlite3_stmt_readonly(X) interface returns true (non-zero) if  | 
4140  |  | ** and only if the [prepared statement] X makes no direct changes to  | 
4141  |  | ** the content of the database file.  | 
4142  |  | **  | 
4143  |  | ** Note that [application-defined SQL functions] or  | 
4144  |  | ** [virtual tables] might change the database indirectly as a side effect.  | 
4145  |  | ** ^(For example, if an application defines a function "eval()" that  | 
4146  |  | ** calls [sqlite3_exec()], then the following SQL statement would  | 
4147  |  | ** change the database file through side-effects:  | 
4148  |  | **  | 
4149  |  | ** <blockquote><pre>  | 
4150  |  | **    SELECT eval('DELETE FROM t1') FROM t2; | 
4151  |  | ** </pre></blockquote>  | 
4152  |  | **  | 
4153  |  | ** But because the [SELECT] statement does not change the database file  | 
4154  |  | ** directly, sqlite3_stmt_readonly() would still return true.)^  | 
4155  |  | **  | 
4156  |  | ** ^Transaction control statements such as [BEGIN], [COMMIT], [ROLLBACK],  | 
4157  |  | ** [SAVEPOINT], and [RELEASE] cause sqlite3_stmt_readonly() to return true,  | 
4158  |  | ** since the statements themselves do not actually modify the database but  | 
4159  |  | ** rather they control the timing of when other statements modify the  | 
4160  |  | ** database.  ^The [ATTACH] and [DETACH] statements also cause  | 
4161  |  | ** sqlite3_stmt_readonly() to return true since, while those statements  | 
4162  |  | ** change the configuration of a database connection, they do not make  | 
4163  |  | ** changes to the content of the database files on disk.  | 
4164  |  | ** ^The sqlite3_stmt_readonly() interface returns true for [BEGIN] since  | 
4165  |  | ** [BEGIN] merely sets internal flags, but the [BEGIN|BEGIN IMMEDIATE] and  | 
4166  |  | ** [BEGIN|BEGIN EXCLUSIVE] commands do touch the database and so  | 
4167  |  | ** sqlite3_stmt_readonly() returns false for those commands.  | 
4168  |  | */  | 
4169  |  | SQLITE_API int sqlite3_stmt_readonly(sqlite3_stmt *pStmt);  | 
4170  |  |  | 
4171  |  | /*  | 
4172  |  | ** CAPI3REF: Query The EXPLAIN Setting For A Prepared Statement  | 
4173  |  | ** METHOD: sqlite3_stmt  | 
4174  |  | **  | 
4175  |  | ** ^The sqlite3_stmt_isexplain(S) interface returns 1 if the  | 
4176  |  | ** prepared statement S is an EXPLAIN statement, or 2 if the  | 
4177  |  | ** statement S is an EXPLAIN QUERY PLAN.  | 
4178  |  | ** ^The sqlite3_stmt_isexplain(S) interface returns 0 if S is  | 
4179  |  | ** an ordinary statement or a NULL pointer.  | 
4180  |  | */  | 
4181  |  | SQLITE_API int sqlite3_stmt_isexplain(sqlite3_stmt *pStmt);  | 
4182  |  |  | 
4183  |  | /*  | 
4184  |  | ** CAPI3REF: Determine If A Prepared Statement Has Been Reset  | 
4185  |  | ** METHOD: sqlite3_stmt  | 
4186  |  | **  | 
4187  |  | ** ^The sqlite3_stmt_busy(S) interface returns true (non-zero) if the  | 
4188  |  | ** [prepared statement] S has been stepped at least once using  | 
4189  |  | ** [sqlite3_step(S)] but has neither run to completion (returned  | 
4190  |  | ** [SQLITE_DONE] from [sqlite3_step(S)]) nor  | 
4191  |  | ** been reset using [sqlite3_reset(S)].  ^The sqlite3_stmt_busy(S)  | 
4192  |  | ** interface returns false if S is a NULL pointer.  If S is not a  | 
4193  |  | ** NULL pointer and is not a pointer to a valid [prepared statement]  | 
4194  |  | ** object, then the behavior is undefined and probably undesirable.  | 
4195  |  | **  | 
4196  |  | ** This interface can be used in combination [sqlite3_next_stmt()]  | 
4197  |  | ** to locate all prepared statements associated with a database  | 
4198  |  | ** connection that are in need of being reset.  This can be used,  | 
4199  |  | ** for example, in diagnostic routines to search for prepared  | 
4200  |  | ** statements that are holding a transaction open.  | 
4201  |  | */  | 
4202  |  | SQLITE_API int sqlite3_stmt_busy(sqlite3_stmt*);  | 
4203  |  |  | 
4204  |  | /*  | 
4205  |  | ** CAPI3REF: Dynamically Typed Value Object  | 
4206  |  | ** KEYWORDS: {protected sqlite3_value} {unprotected sqlite3_value} | 
4207  |  | **  | 
4208  |  | ** SQLite uses the sqlite3_value object to represent all values  | 
4209  |  | ** that can be stored in a database table. SQLite uses dynamic typing  | 
4210  |  | ** for the values it stores.  ^Values stored in sqlite3_value objects  | 
4211  |  | ** can be integers, floating point values, strings, BLOBs, or NULL.  | 
4212  |  | **  | 
4213  |  | ** An sqlite3_value object may be either "protected" or "unprotected".  | 
4214  |  | ** Some interfaces require a protected sqlite3_value.  Other interfaces  | 
4215  |  | ** will accept either a protected or an unprotected sqlite3_value.  | 
4216  |  | ** Every interface that accepts sqlite3_value arguments specifies  | 
4217  |  | ** whether or not it requires a protected sqlite3_value.  The  | 
4218  |  | ** [sqlite3_value_dup()] interface can be used to construct a new  | 
4219  |  | ** protected sqlite3_value from an unprotected sqlite3_value.  | 
4220  |  | **  | 
4221  |  | ** The terms "protected" and "unprotected" refer to whether or not  | 
4222  |  | ** a mutex is held.  An internal mutex is held for a protected  | 
4223  |  | ** sqlite3_value object but no mutex is held for an unprotected  | 
4224  |  | ** sqlite3_value object.  If SQLite is compiled to be single-threaded  | 
4225  |  | ** (with [SQLITE_THREADSAFE=0] and with [sqlite3_threadsafe()] returning 0)  | 
4226  |  | ** or if SQLite is run in one of reduced mutex modes  | 
4227  |  | ** [SQLITE_CONFIG_SINGLETHREAD] or [SQLITE_CONFIG_MULTITHREAD]  | 
4228  |  | ** then there is no distinction between protected and unprotected  | 
4229  |  | ** sqlite3_value objects and they can be used interchangeably.  However,  | 
4230  |  | ** for maximum code portability it is recommended that applications  | 
4231  |  | ** still make the distinction between protected and unprotected  | 
4232  |  | ** sqlite3_value objects even when not strictly required.  | 
4233  |  | **  | 
4234  |  | ** ^The sqlite3_value objects that are passed as parameters into the  | 
4235  |  | ** implementation of [application-defined SQL functions] are protected.  | 
4236  |  | ** ^The sqlite3_value object returned by  | 
4237  |  | ** [sqlite3_column_value()] is unprotected.  | 
4238  |  | ** Unprotected sqlite3_value objects may only be used as arguments  | 
4239  |  | ** to [sqlite3_result_value()], [sqlite3_bind_value()], and  | 
4240  |  | ** [sqlite3_value_dup()].  | 
4241  |  | ** The [sqlite3_value_blob | sqlite3_value_type()] family of  | 
4242  |  | ** interfaces require protected sqlite3_value objects.  | 
4243  |  | */  | 
4244  |  | typedef struct sqlite3_value sqlite3_value;  | 
4245  |  |  | 
4246  |  | /*  | 
4247  |  | ** CAPI3REF: SQL Function Context Object  | 
4248  |  | **  | 
4249  |  | ** The context in which an SQL function executes is stored in an  | 
4250  |  | ** sqlite3_context object.  ^A pointer to an sqlite3_context object  | 
4251  |  | ** is always first parameter to [application-defined SQL functions].  | 
4252  |  | ** The application-defined SQL function implementation will pass this  | 
4253  |  | ** pointer through into calls to [sqlite3_result_int | sqlite3_result()],  | 
4254  |  | ** [sqlite3_aggregate_context()], [sqlite3_user_data()],  | 
4255  |  | ** [sqlite3_context_db_handle()], [sqlite3_get_auxdata()],  | 
4256  |  | ** and/or [sqlite3_set_auxdata()].  | 
4257  |  | */  | 
4258  |  | typedef struct sqlite3_context sqlite3_context;  | 
4259  |  |  | 
4260  |  | /*  | 
4261  |  | ** CAPI3REF: Binding Values To Prepared Statements  | 
4262  |  | ** KEYWORDS: {host parameter} {host parameters} {host parameter name} | 
4263  |  | ** KEYWORDS: {SQL parameter} {SQL parameters} {parameter binding} | 
4264  |  | ** METHOD: sqlite3_stmt  | 
4265  |  | **  | 
4266  |  | ** ^(In the SQL statement text input to [sqlite3_prepare_v2()] and its variants,  | 
4267  |  | ** literals may be replaced by a [parameter] that matches one of following  | 
4268  |  | ** templates:  | 
4269  |  | **  | 
4270  |  | ** <ul>  | 
4271  |  | ** <li>  ?  | 
4272  |  | ** <li>  ?NNN  | 
4273  |  | ** <li>  :VVV  | 
4274  |  | ** <li>  @VVV  | 
4275  |  | ** <li>  $VVV  | 
4276  |  | ** </ul>  | 
4277  |  | **  | 
4278  |  | ** In the templates above, NNN represents an integer literal,  | 
4279  |  | ** and VVV represents an alphanumeric identifier.)^  ^The values of these  | 
4280  |  | ** parameters (also called "host parameter names" or "SQL parameters")  | 
4281  |  | ** can be set using the sqlite3_bind_*() routines defined here.  | 
4282  |  | **  | 
4283  |  | ** ^The first argument to the sqlite3_bind_*() routines is always  | 
4284  |  | ** a pointer to the [sqlite3_stmt] object returned from  | 
4285  |  | ** [sqlite3_prepare_v2()] or its variants.  | 
4286  |  | **  | 
4287  |  | ** ^The second argument is the index of the SQL parameter to be set.  | 
4288  |  | ** ^The leftmost SQL parameter has an index of 1.  ^When the same named  | 
4289  |  | ** SQL parameter is used more than once, second and subsequent  | 
4290  |  | ** occurrences have the same index as the first occurrence.  | 
4291  |  | ** ^The index for named parameters can be looked up using the  | 
4292  |  | ** [sqlite3_bind_parameter_index()] API if desired.  ^The index  | 
4293  |  | ** for "?NNN" parameters is the value of NNN.  | 
4294  |  | ** ^The NNN value must be between 1 and the [sqlite3_limit()]  | 
4295  |  | ** parameter [SQLITE_LIMIT_VARIABLE_NUMBER] (default value: 32766).  | 
4296  |  | **  | 
4297  |  | ** ^The third argument is the value to bind to the parameter.  | 
4298  |  | ** ^If the third parameter to sqlite3_bind_text() or sqlite3_bind_text16()  | 
4299  |  | ** or sqlite3_bind_blob() is a NULL pointer then the fourth parameter  | 
4300  |  | ** is ignored and the end result is the same as sqlite3_bind_null().  | 
4301  |  | ** ^If the third parameter to sqlite3_bind_text() is not NULL, then  | 
4302  |  | ** it should be a pointer to well-formed UTF8 text.  | 
4303  |  | ** ^If the third parameter to sqlite3_bind_text16() is not NULL, then  | 
4304  |  | ** it should be a pointer to well-formed UTF16 text.  | 
4305  |  | ** ^If the third parameter to sqlite3_bind_text64() is not NULL, then  | 
4306  |  | ** it should be a pointer to a well-formed unicode string that is  | 
4307  |  | ** either UTF8 if the sixth parameter is SQLITE_UTF8, or UTF16  | 
4308  |  | ** otherwise.  | 
4309  |  | **  | 
4310  |  | ** [[byte-order determination rules]] ^The byte-order of  | 
4311  |  | ** UTF16 input text is determined by the byte-order mark (BOM, U+FEFF)  | 
4312  |  | ** found in first character, which is removed, or in the absence of a BOM  | 
4313  |  | ** the byte order is the native byte order of the host  | 
4314  |  | ** machine for sqlite3_bind_text16() or the byte order specified in  | 
4315  |  | ** the 6th parameter for sqlite3_bind_text64().)^  | 
4316  |  | ** ^If UTF16 input text contains invalid unicode  | 
4317  |  | ** characters, then SQLite might change those invalid characters  | 
4318  |  | ** into the unicode replacement character: U+FFFD.  | 
4319  |  | **  | 
4320  |  | ** ^(In those routines that have a fourth argument, its value is the  | 
4321  |  | ** number of bytes in the parameter.  To be clear: the value is the  | 
4322  |  | ** number of <u>bytes</u> in the value, not the number of characters.)^  | 
4323  |  | ** ^If the fourth parameter to sqlite3_bind_text() or sqlite3_bind_text16()  | 
4324  |  | ** is negative, then the length of the string is  | 
4325  |  | ** the number of bytes up to the first zero terminator.  | 
4326  |  | ** If the fourth parameter to sqlite3_bind_blob() is negative, then  | 
4327  |  | ** the behavior is undefined.  | 
4328  |  | ** If a non-negative fourth parameter is provided to sqlite3_bind_text()  | 
4329  |  | ** or sqlite3_bind_text16() or sqlite3_bind_text64() then  | 
4330  |  | ** that parameter must be the byte offset  | 
4331  |  | ** where the NUL terminator would occur assuming the string were NUL  | 
4332  |  | ** terminated.  If any NUL characters occurs at byte offsets less than  | 
4333  |  | ** the value of the fourth parameter then the resulting string value will  | 
4334  |  | ** contain embedded NULs.  The result of expressions involving strings  | 
4335  |  | ** with embedded NULs is undefined.  | 
4336  |  | **  | 
4337  |  | ** ^The fifth argument to the BLOB and string binding interfaces  | 
4338  |  | ** is a destructor used to dispose of the BLOB or  | 
4339  |  | ** string after SQLite has finished with it.  ^The destructor is called  | 
4340  |  | ** to dispose of the BLOB or string even if the call to the bind API fails,  | 
4341  |  | ** except the destructor is not called if the third parameter is a NULL  | 
4342  |  | ** pointer or the fourth parameter is negative.  | 
4343  |  | ** ^If the fifth argument is  | 
4344  |  | ** the special value [SQLITE_STATIC], then SQLite assumes that the  | 
4345  |  | ** information is in static, unmanaged space and does not need to be freed.  | 
4346  |  | ** ^If the fifth argument has the value [SQLITE_TRANSIENT], then  | 
4347  |  | ** SQLite makes its own private copy of the data immediately, before  | 
4348  |  | ** the sqlite3_bind_*() routine returns.  | 
4349  |  | **  | 
4350  |  | ** ^The sixth argument to sqlite3_bind_text64() must be one of  | 
4351  |  | ** [SQLITE_UTF8], [SQLITE_UTF16], [SQLITE_UTF16BE], or [SQLITE_UTF16LE]  | 
4352  |  | ** to specify the encoding of the text in the third parameter.  If  | 
4353  |  | ** the sixth argument to sqlite3_bind_text64() is not one of the  | 
4354  |  | ** allowed values shown above, or if the text encoding is different  | 
4355  |  | ** from the encoding specified by the sixth parameter, then the behavior  | 
4356  |  | ** is undefined.  | 
4357  |  | **  | 
4358  |  | ** ^The sqlite3_bind_zeroblob() routine binds a BLOB of length N that  | 
4359  |  | ** is filled with zeroes.  ^A zeroblob uses a fixed amount of memory  | 
4360  |  | ** (just an integer to hold its size) while it is being processed.  | 
4361  |  | ** Zeroblobs are intended to serve as placeholders for BLOBs whose  | 
4362  |  | ** content is later written using  | 
4363  |  | ** [sqlite3_blob_open | incremental BLOB I/O] routines.  | 
4364  |  | ** ^A negative value for the zeroblob results in a zero-length BLOB.  | 
4365  |  | **  | 
4366  |  | ** ^The sqlite3_bind_pointer(S,I,P,T,D) routine causes the I-th parameter in  | 
4367  |  | ** [prepared statement] S to have an SQL value of NULL, but to also be  | 
4368  |  | ** associated with the pointer P of type T.  ^D is either a NULL pointer or  | 
4369  |  | ** a pointer to a destructor function for P. ^SQLite will invoke the  | 
4370  |  | ** destructor D with a single argument of P when it is finished using  | 
4371  |  | ** P.  The T parameter should be a static string, preferably a string  | 
4372  |  | ** literal. The sqlite3_bind_pointer() routine is part of the  | 
4373  |  | ** [pointer passing interface] added for SQLite 3.20.0.  | 
4374  |  | **  | 
4375  |  | ** ^If any of the sqlite3_bind_*() routines are called with a NULL pointer  | 
4376  |  | ** for the [prepared statement] or with a prepared statement for which  | 
4377  |  | ** [sqlite3_step()] has been called more recently than [sqlite3_reset()],  | 
4378  |  | ** then the call will return [SQLITE_MISUSE].  If any sqlite3_bind_()  | 
4379  |  | ** routine is passed a [prepared statement] that has been finalized, the  | 
4380  |  | ** result is undefined and probably harmful.  | 
4381  |  | **  | 
4382  |  | ** ^Bindings are not cleared by the [sqlite3_reset()] routine.  | 
4383  |  | ** ^Unbound parameters are interpreted as NULL.  | 
4384  |  | **  | 
4385  |  | ** ^The sqlite3_bind_* routines return [SQLITE_OK] on success or an  | 
4386  |  | ** [error code] if anything goes wrong.  | 
4387  |  | ** ^[SQLITE_TOOBIG] might be returned if the size of a string or BLOB  | 
4388  |  | ** exceeds limits imposed by [sqlite3_limit]([SQLITE_LIMIT_LENGTH]) or  | 
4389  |  | ** [SQLITE_MAX_LENGTH].  | 
4390  |  | ** ^[SQLITE_RANGE] is returned if the parameter  | 
4391  |  | ** index is out of range.  ^[SQLITE_NOMEM] is returned if malloc() fails.  | 
4392  |  | **  | 
4393  |  | ** See also: [sqlite3_bind_parameter_count()],  | 
4394  |  | ** [sqlite3_bind_parameter_name()], and [sqlite3_bind_parameter_index()].  | 
4395  |  | */  | 
4396  |  | SQLITE_API int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*));  | 
4397  |  | SQLITE_API int sqlite3_bind_blob64(sqlite3_stmt*, int, const void*, sqlite3_uint64,  | 
4398  |  |                         void(*)(void*));  | 
4399  |  | SQLITE_API int sqlite3_bind_double(sqlite3_stmt*, int, double);  | 
4400  |  | SQLITE_API int sqlite3_bind_int(sqlite3_stmt*, int, int);  | 
4401  |  | SQLITE_API int sqlite3_bind_int64(sqlite3_stmt*, int, sqlite3_int64);  | 
4402  |  | SQLITE_API int sqlite3_bind_null(sqlite3_stmt*, int);  | 
4403  |  | SQLITE_API int sqlite3_bind_text(sqlite3_stmt*,int,const char*,int,void(*)(void*));  | 
4404  |  | SQLITE_API int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int, void(*)(void*));  | 
4405  |  | SQLITE_API int sqlite3_bind_text64(sqlite3_stmt*, int, const char*, sqlite3_uint64,  | 
4406  |  |                          void(*)(void*), unsigned char encoding);  | 
4407  |  | SQLITE_API int sqlite3_bind_value(sqlite3_stmt*, int, const sqlite3_value*);  | 
4408  |  | SQLITE_API int sqlite3_bind_pointer(sqlite3_stmt*, int, void*, const char*,void(*)(void*));  | 
4409  |  | SQLITE_API int sqlite3_bind_zeroblob(sqlite3_stmt*, int, int n);  | 
4410  |  | SQLITE_API int sqlite3_bind_zeroblob64(sqlite3_stmt*, int, sqlite3_uint64);  | 
4411  |  |  | 
4412  |  | /*  | 
4413  |  | ** CAPI3REF: Number Of SQL Parameters  | 
4414  |  | ** METHOD: sqlite3_stmt  | 
4415  |  | **  | 
4416  |  | ** ^This routine can be used to find the number of [SQL parameters]  | 
4417  |  | ** in a [prepared statement].  SQL parameters are tokens of the  | 
4418  |  | ** form "?", "?NNN", ":AAA", "$AAA", or "@AAA" that serve as  | 
4419  |  | ** placeholders for values that are [sqlite3_bind_blob | bound]  | 
4420  |  | ** to the parameters at a later time.  | 
4421  |  | **  | 
4422  |  | ** ^(This routine actually returns the index of the largest (rightmost)  | 
4423  |  | ** parameter. For all forms except ?NNN, this will correspond to the  | 
4424  |  | ** number of unique parameters.  If parameters of the ?NNN form are used,  | 
4425  |  | ** there may be gaps in the list.)^  | 
4426  |  | **  | 
4427  |  | ** See also: [sqlite3_bind_blob|sqlite3_bind()],  | 
4428  |  | ** [sqlite3_bind_parameter_name()], and  | 
4429  |  | ** [sqlite3_bind_parameter_index()].  | 
4430  |  | */  | 
4431  |  | SQLITE_API int sqlite3_bind_parameter_count(sqlite3_stmt*);  | 
4432  |  |  | 
4433  |  | /*  | 
4434  |  | ** CAPI3REF: Name Of A Host Parameter  | 
4435  |  | ** METHOD: sqlite3_stmt  | 
4436  |  | **  | 
4437  |  | ** ^The sqlite3_bind_parameter_name(P,N) interface returns  | 
4438  |  | ** the name of the N-th [SQL parameter] in the [prepared statement] P.  | 
4439  |  | ** ^(SQL parameters of the form "?NNN" or ":AAA" or "@AAA" or "$AAA"  | 
4440  |  | ** have a name which is the string "?NNN" or ":AAA" or "@AAA" or "$AAA"  | 
4441  |  | ** respectively.  | 
4442  |  | ** In other words, the initial ":" or "$" or "@" or "?"  | 
4443  |  | ** is included as part of the name.)^  | 
4444  |  | ** ^Parameters of the form "?" without a following integer have no name  | 
4445  |  | ** and are referred to as "nameless" or "anonymous parameters".  | 
4446  |  | **  | 
4447  |  | ** ^The first host parameter has an index of 1, not 0.  | 
4448  |  | **  | 
4449  |  | ** ^If the value N is out of range or if the N-th parameter is  | 
4450  |  | ** nameless, then NULL is returned.  ^The returned string is  | 
4451  |  | ** always in UTF-8 encoding even if the named parameter was  | 
4452  |  | ** originally specified as UTF-16 in [sqlite3_prepare16()],  | 
4453  |  | ** [sqlite3_prepare16_v2()], or [sqlite3_prepare16_v3()].  | 
4454  |  | **  | 
4455  |  | ** See also: [sqlite3_bind_blob|sqlite3_bind()],  | 
4456  |  | ** [sqlite3_bind_parameter_count()], and  | 
4457  |  | ** [sqlite3_bind_parameter_index()].  | 
4458  |  | */  | 
4459  |  | SQLITE_API const char *sqlite3_bind_parameter_name(sqlite3_stmt*, int);  | 
4460  |  |  | 
4461  |  | /*  | 
4462  |  | ** CAPI3REF: Index Of A Parameter With A Given Name  | 
4463  |  | ** METHOD: sqlite3_stmt  | 
4464  |  | **  | 
4465  |  | ** ^Return the index of an SQL parameter given its name.  ^The  | 
4466  |  | ** index value returned is suitable for use as the second  | 
4467  |  | ** parameter to [sqlite3_bind_blob|sqlite3_bind()].  ^A zero  | 
4468  |  | ** is returned if no matching parameter is found.  ^The parameter  | 
4469  |  | ** name must be given in UTF-8 even if the original statement  | 
4470  |  | ** was prepared from UTF-16 text using [sqlite3_prepare16_v2()] or  | 
4471  |  | ** [sqlite3_prepare16_v3()].  | 
4472  |  | **  | 
4473  |  | ** See also: [sqlite3_bind_blob|sqlite3_bind()],  | 
4474  |  | ** [sqlite3_bind_parameter_count()], and  | 
4475  |  | ** [sqlite3_bind_parameter_name()].  | 
4476  |  | */  | 
4477  |  | SQLITE_API int sqlite3_bind_parameter_index(sqlite3_stmt*, const char *zName);  | 
4478  |  |  | 
4479  |  | /*  | 
4480  |  | ** CAPI3REF: Reset All Bindings On A Prepared Statement  | 
4481  |  | ** METHOD: sqlite3_stmt  | 
4482  |  | **  | 
4483  |  | ** ^Contrary to the intuition of many, [sqlite3_reset()] does not reset  | 
4484  |  | ** the [sqlite3_bind_blob | bindings] on a [prepared statement].  | 
4485  |  | ** ^Use this routine to reset all host parameters to NULL.  | 
4486  |  | */  | 
4487  |  | SQLITE_API int sqlite3_clear_bindings(sqlite3_stmt*);  | 
4488  |  |  | 
4489  |  | /*  | 
4490  |  | ** CAPI3REF: Number Of Columns In A Result Set  | 
4491  |  | ** METHOD: sqlite3_stmt  | 
4492  |  | **  | 
4493  |  | ** ^Return the number of columns in the result set returned by the  | 
4494  |  | ** [prepared statement]. ^If this routine returns 0, that means the  | 
4495  |  | ** [prepared statement] returns no data (for example an [UPDATE]).  | 
4496  |  | ** ^However, just because this routine returns a positive number does not  | 
4497  |  | ** mean that one or more rows of data will be returned.  ^A SELECT statement  | 
4498  |  | ** will always have a positive sqlite3_column_count() but depending on the  | 
4499  |  | ** WHERE clause constraints and the table content, it might return no rows.  | 
4500  |  | **  | 
4501  |  | ** See also: [sqlite3_data_count()]  | 
4502  |  | */  | 
4503  |  | SQLITE_API int sqlite3_column_count(sqlite3_stmt *pStmt);  | 
4504  |  |  | 
4505  |  | /*  | 
4506  |  | ** CAPI3REF: Column Names In A Result Set  | 
4507  |  | ** METHOD: sqlite3_stmt  | 
4508  |  | **  | 
4509  |  | ** ^These routines return the name assigned to a particular column  | 
4510  |  | ** in the result set of a [SELECT] statement.  ^The sqlite3_column_name()  | 
4511  |  | ** interface returns a pointer to a zero-terminated UTF-8 string  | 
4512  |  | ** and sqlite3_column_name16() returns a pointer to a zero-terminated  | 
4513  |  | ** UTF-16 string.  ^The first parameter is the [prepared statement]  | 
4514  |  | ** that implements the [SELECT] statement. ^The second parameter is the  | 
4515  |  | ** column number.  ^The leftmost column is number 0.  | 
4516  |  | **  | 
4517  |  | ** ^The returned string pointer is valid until either the [prepared statement]  | 
4518  |  | ** is destroyed by [sqlite3_finalize()] or until the statement is automatically  | 
4519  |  | ** reprepared by the first call to [sqlite3_step()] for a particular run  | 
4520  |  | ** or until the next call to  | 
4521  |  | ** sqlite3_column_name() or sqlite3_column_name16() on the same column.  | 
4522  |  | **  | 
4523  |  | ** ^If sqlite3_malloc() fails during the processing of either routine  | 
4524  |  | ** (for example during a conversion from UTF-8 to UTF-16) then a  | 
4525  |  | ** NULL pointer is returned.  | 
4526  |  | **  | 
4527  |  | ** ^The name of a result column is the value of the "AS" clause for  | 
4528  |  | ** that column, if there is an AS clause.  If there is no AS clause  | 
4529  |  | ** then the name of the column is unspecified and may change from  | 
4530  |  | ** one release of SQLite to the next.  | 
4531  |  | */  | 
4532  |  | SQLITE_API const char *sqlite3_column_name(sqlite3_stmt*, int N);  | 
4533  |  | SQLITE_API const void *sqlite3_column_name16(sqlite3_stmt*, int N);  | 
4534  |  |  | 
4535  |  | /*  | 
4536  |  | ** CAPI3REF: Source Of Data In A Query Result  | 
4537  |  | ** METHOD: sqlite3_stmt  | 
4538  |  | **  | 
4539  |  | ** ^These routines provide a means to determine the database, table, and  | 
4540  |  | ** table column that is the origin of a particular result column in  | 
4541  |  | ** [SELECT] statement.  | 
4542  |  | ** ^The name of the database or table or column can be returned as  | 
4543  |  | ** either a UTF-8 or UTF-16 string.  ^The _database_ routines return  | 
4544  |  | ** the database name, the _table_ routines return the table name, and  | 
4545  |  | ** the origin_ routines return the column name.  | 
4546  |  | ** ^The returned string is valid until the [prepared statement] is destroyed  | 
4547  |  | ** using [sqlite3_finalize()] or until the statement is automatically  | 
4548  |  | ** reprepared by the first call to [sqlite3_step()] for a particular run  | 
4549  |  | ** or until the same information is requested  | 
4550  |  | ** again in a different encoding.  | 
4551  |  | **  | 
4552  |  | ** ^The names returned are the original un-aliased names of the  | 
4553  |  | ** database, table, and column.  | 
4554  |  | **  | 
4555  |  | ** ^The first argument to these interfaces is a [prepared statement].  | 
4556  |  | ** ^These functions return information about the Nth result column returned by  | 
4557  |  | ** the statement, where N is the second function argument.  | 
4558  |  | ** ^The left-most column is column 0 for these routines.  | 
4559  |  | **  | 
4560  |  | ** ^If the Nth column returned by the statement is an expression or  | 
4561  |  | ** subquery and is not a column value, then all of these functions return  | 
4562  |  | ** NULL.  ^These routines might also return NULL if a memory allocation error  | 
4563  |  | ** occurs.  ^Otherwise, they return the name of the attached database, table,  | 
4564  |  | ** or column that query result column was extracted from.  | 
4565  |  | **  | 
4566  |  | ** ^As with all other SQLite APIs, those whose names end with "16" return  | 
4567  |  | ** UTF-16 encoded strings and the other functions return UTF-8.  | 
4568  |  | **  | 
4569  |  | ** ^These APIs are only available if the library was compiled with the  | 
4570  |  | ** [SQLITE_ENABLE_COLUMN_METADATA] C-preprocessor symbol.  | 
4571  |  | **  | 
4572  |  | ** If two or more threads call one or more  | 
4573  |  | ** [sqlite3_column_database_name | column metadata interfaces]  | 
4574  |  | ** for the same [prepared statement] and result column  | 
4575  |  | ** at the same time then the results are undefined.  | 
4576  |  | */  | 
4577  |  | SQLITE_API const char *sqlite3_column_database_name(sqlite3_stmt*,int);  | 
4578  |  | SQLITE_API const void *sqlite3_column_database_name16(sqlite3_stmt*,int);  | 
4579  |  | SQLITE_API const char *sqlite3_column_table_name(sqlite3_stmt*,int);  | 
4580  |  | SQLITE_API const void *sqlite3_column_table_name16(sqlite3_stmt*,int);  | 
4581  |  | SQLITE_API const char *sqlite3_column_origin_name(sqlite3_stmt*,int);  | 
4582  |  | SQLITE_API const void *sqlite3_column_origin_name16(sqlite3_stmt*,int);  | 
4583  |  |  | 
4584  |  | /*  | 
4585  |  | ** CAPI3REF: Declared Datatype Of A Query Result  | 
4586  |  | ** METHOD: sqlite3_stmt  | 
4587  |  | **  | 
4588  |  | ** ^(The first parameter is a [prepared statement].  | 
4589  |  | ** If this statement is a [SELECT] statement and the Nth column of the  | 
4590  |  | ** returned result set of that [SELECT] is a table column (not an  | 
4591  |  | ** expression or subquery) then the declared type of the table  | 
4592  |  | ** column is returned.)^  ^If the Nth column of the result set is an  | 
4593  |  | ** expression or subquery, then a NULL pointer is returned.  | 
4594  |  | ** ^The returned string is always UTF-8 encoded.  | 
4595  |  | **  | 
4596  |  | ** ^(For example, given the database schema:  | 
4597  |  | **  | 
4598  |  | ** CREATE TABLE t1(c1 VARIANT);  | 
4599  |  | **  | 
4600  |  | ** and the following statement to be compiled:  | 
4601  |  | **  | 
4602  |  | ** SELECT c1 + 1, c1 FROM t1;  | 
4603  |  | **  | 
4604  |  | ** this routine would return the string "VARIANT" for the second result  | 
4605  |  | ** column (i==1), and a NULL pointer for the first result column (i==0).)^  | 
4606  |  | **  | 
4607  |  | ** ^SQLite uses dynamic run-time typing.  ^So just because a column  | 
4608  |  | ** is declared to contain a particular type does not mean that the  | 
4609  |  | ** data stored in that column is of the declared type.  SQLite is  | 
4610  |  | ** strongly typed, but the typing is dynamic not static.  ^Type  | 
4611  |  | ** is associated with individual values, not with the containers  | 
4612  |  | ** used to hold those values.  | 
4613  |  | */  | 
4614  |  | SQLITE_API const char *sqlite3_column_decltype(sqlite3_stmt*,int);  | 
4615  |  | SQLITE_API const void *sqlite3_column_decltype16(sqlite3_stmt*,int);  | 
4616  |  |  | 
4617  |  | /*  | 
4618  |  | ** CAPI3REF: Evaluate An SQL Statement  | 
4619  |  | ** METHOD: sqlite3_stmt  | 
4620  |  | **  | 
4621  |  | ** After a [prepared statement] has been prepared using any of  | 
4622  |  | ** [sqlite3_prepare_v2()], [sqlite3_prepare_v3()], [sqlite3_prepare16_v2()],  | 
4623  |  | ** or [sqlite3_prepare16_v3()] or one of the legacy  | 
4624  |  | ** interfaces [sqlite3_prepare()] or [sqlite3_prepare16()], this function  | 
4625  |  | ** must be called one or more times to evaluate the statement.  | 
4626  |  | **  | 
4627  |  | ** The details of the behavior of the sqlite3_step() interface depend  | 
4628  |  | ** on whether the statement was prepared using the newer "vX" interfaces  | 
4629  |  | ** [sqlite3_prepare_v3()], [sqlite3_prepare_v2()], [sqlite3_prepare16_v3()],  | 
4630  |  | ** [sqlite3_prepare16_v2()] or the older legacy  | 
4631  |  | ** interfaces [sqlite3_prepare()] and [sqlite3_prepare16()].  The use of the  | 
4632  |  | ** new "vX" interface is recommended for new applications but the legacy  | 
4633  |  | ** interface will continue to be supported.  | 
4634  |  | **  | 
4635  |  | ** ^In the legacy interface, the return value will be either [SQLITE_BUSY],  | 
4636  |  | ** [SQLITE_DONE], [SQLITE_ROW], [SQLITE_ERROR], or [SQLITE_MISUSE].  | 
4637  |  | ** ^With the "v2" interface, any of the other [result codes] or  | 
4638  |  | ** [extended result codes] might be returned as well.  | 
4639  |  | **  | 
4640  |  | ** ^[SQLITE_BUSY] means that the database engine was unable to acquire the  | 
4641  |  | ** database locks it needs to do its job.  ^If the statement is a [COMMIT]  | 
4642  |  | ** or occurs outside of an explicit transaction, then you can retry the  | 
4643  |  | ** statement.  If the statement is not a [COMMIT] and occurs within an  | 
4644  |  | ** explicit transaction then you should rollback the transaction before  | 
4645  |  | ** continuing.  | 
4646  |  | **  | 
4647  |  | ** ^[SQLITE_DONE] means that the statement has finished executing  | 
4648  |  | ** successfully.  sqlite3_step() should not be called again on this virtual  | 
4649  |  | ** machine without first calling [sqlite3_reset()] to reset the virtual  | 
4650  |  | ** machine back to its initial state.  | 
4651  |  | **  | 
4652  |  | ** ^If the SQL statement being executed returns any data, then [SQLITE_ROW]  | 
4653  |  | ** is returned each time a new row of data is ready for processing by the  | 
4654  |  | ** caller. The values may be accessed using the [column access functions].  | 
4655  |  | ** sqlite3_step() is called again to retrieve the next row of data.  | 
4656  |  | **  | 
4657  |  | ** ^[SQLITE_ERROR] means that a run-time error (such as a constraint  | 
4658  |  | ** violation) has occurred.  sqlite3_step() should not be called again on  | 
4659  |  | ** the VM. More information may be found by calling [sqlite3_errmsg()].  | 
4660  |  | ** ^With the legacy interface, a more specific error code (for example,  | 
4661  |  | ** [SQLITE_INTERRUPT], [SQLITE_SCHEMA], [SQLITE_CORRUPT], and so forth)  | 
4662  |  | ** can be obtained by calling [sqlite3_reset()] on the  | 
4663  |  | ** [prepared statement].  ^In the "v2" interface,  | 
4664  |  | ** the more specific error code is returned directly by sqlite3_step().  | 
4665  |  | **  | 
4666  |  | ** [SQLITE_MISUSE] means that the this routine was called inappropriately.  | 
4667  |  | ** Perhaps it was called on a [prepared statement] that has  | 
4668  |  | ** already been [sqlite3_finalize | finalized] or on one that had  | 
4669  |  | ** previously returned [SQLITE_ERROR] or [SQLITE_DONE].  Or it could  | 
4670  |  | ** be the case that the same database connection is being used by two or  | 
4671  |  | ** more threads at the same moment in time.  | 
4672  |  | **  | 
4673  |  | ** For all versions of SQLite up to and including 3.6.23.1, a call to  | 
4674  |  | ** [sqlite3_reset()] was required after sqlite3_step() returned anything  | 
4675  |  | ** other than [SQLITE_ROW] before any subsequent invocation of  | 
4676  |  | ** sqlite3_step().  Failure to reset the prepared statement using  | 
4677  |  | ** [sqlite3_reset()] would result in an [SQLITE_MISUSE] return from  | 
4678  |  | ** sqlite3_step().  But after [version 3.6.23.1] ([dateof:3.6.23.1],  | 
4679  |  | ** sqlite3_step() began  | 
4680  |  | ** calling [sqlite3_reset()] automatically in this circumstance rather  | 
4681  |  | ** than returning [SQLITE_MISUSE].  This is not considered a compatibility  | 
4682  |  | ** break because any application that ever receives an SQLITE_MISUSE error  | 
4683  |  | ** is broken by definition.  The [SQLITE_OMIT_AUTORESET] compile-time option  | 
4684  |  | ** can be used to restore the legacy behavior.  | 
4685  |  | **  | 
4686  |  | ** <b>Goofy Interface Alert:</b> In the legacy interface, the sqlite3_step()  | 
4687  |  | ** API always returns a generic error code, [SQLITE_ERROR], following any  | 
4688  |  | ** error other than [SQLITE_BUSY] and [SQLITE_MISUSE].  You must call  | 
4689  |  | ** [sqlite3_reset()] or [sqlite3_finalize()] in order to find one of the  | 
4690  |  | ** specific [error codes] that better describes the error.  | 
4691  |  | ** We admit that this is a goofy design.  The problem has been fixed  | 
4692  |  | ** with the "v2" interface.  If you prepare all of your SQL statements  | 
4693  |  | ** using [sqlite3_prepare_v3()] or [sqlite3_prepare_v2()]  | 
4694  |  | ** or [sqlite3_prepare16_v2()] or [sqlite3_prepare16_v3()] instead  | 
4695  |  | ** of the legacy [sqlite3_prepare()] and [sqlite3_prepare16()] interfaces,  | 
4696  |  | ** then the more specific [error codes] are returned directly  | 
4697  |  | ** by sqlite3_step().  The use of the "vX" interfaces is recommended.  | 
4698  |  | */  | 
4699  |  | SQLITE_API int sqlite3_step(sqlite3_stmt*);  | 
4700  |  |  | 
4701  |  | /*  | 
4702  |  | ** CAPI3REF: Number of columns in a result set  | 
4703  |  | ** METHOD: sqlite3_stmt  | 
4704  |  | **  | 
4705  |  | ** ^The sqlite3_data_count(P) interface returns the number of columns in the  | 
4706  |  | ** current row of the result set of [prepared statement] P.  | 
4707  |  | ** ^If prepared statement P does not have results ready to return  | 
4708  |  | ** (via calls to the [sqlite3_column_int | sqlite3_column()] family of  | 
4709  |  | ** interfaces) then sqlite3_data_count(P) returns 0.  | 
4710  |  | ** ^The sqlite3_data_count(P) routine also returns 0 if P is a NULL pointer.  | 
4711  |  | ** ^The sqlite3_data_count(P) routine returns 0 if the previous call to  | 
4712  |  | ** [sqlite3_step](P) returned [SQLITE_DONE].  ^The sqlite3_data_count(P)  | 
4713  |  | ** will return non-zero if previous call to [sqlite3_step](P) returned  | 
4714  |  | ** [SQLITE_ROW], except in the case of the [PRAGMA incremental_vacuum]  | 
4715  |  | ** where it always returns zero since each step of that multi-step  | 
4716  |  | ** pragma returns 0 columns of data.  | 
4717  |  | **  | 
4718  |  | ** See also: [sqlite3_column_count()]  | 
4719  |  | */  | 
4720  |  | SQLITE_API int sqlite3_data_count(sqlite3_stmt *pStmt);  | 
4721  |  |  | 
4722  |  | /*  | 
4723  |  | ** CAPI3REF: Fundamental Datatypes  | 
4724  |  | ** KEYWORDS: SQLITE_TEXT  | 
4725  |  | **  | 
4726  |  | ** ^(Every value in SQLite has one of five fundamental datatypes:  | 
4727  |  | **  | 
4728  |  | ** <ul>  | 
4729  |  | ** <li> 64-bit signed integer  | 
4730  |  | ** <li> 64-bit IEEE floating point number  | 
4731  |  | ** <li> string  | 
4732  |  | ** <li> BLOB  | 
4733  |  | ** <li> NULL  | 
4734  |  | ** </ul>)^  | 
4735  |  | **  | 
4736  |  | ** These constants are codes for each of those types.  | 
4737  |  | **  | 
4738  |  | ** Note that the SQLITE_TEXT constant was also used in SQLite version 2  | 
4739  |  | ** for a completely different meaning.  Software that links against both  | 
4740  |  | ** SQLite version 2 and SQLite version 3 should use SQLITE3_TEXT, not  | 
4741  |  | ** SQLITE_TEXT.  | 
4742  |  | */  | 
4743  |  | #define SQLITE_INTEGER  1  | 
4744  |  | #define SQLITE_FLOAT    2  | 
4745  |  | #define SQLITE_BLOB     4  | 
4746  |  | #define SQLITE_NULL     5  | 
4747  |  | #ifdef SQLITE_TEXT  | 
4748  |  | # undef SQLITE_TEXT  | 
4749  |  | #else  | 
4750  |  | # define SQLITE_TEXT     3  | 
4751  |  | #endif  | 
4752  |  | #define SQLITE3_TEXT     3  | 
4753  |  |  | 
4754  |  | /*  | 
4755  |  | ** CAPI3REF: Result Values From A Query  | 
4756  |  | ** KEYWORDS: {column access functions} | 
4757  |  | ** METHOD: sqlite3_stmt  | 
4758  |  | **  | 
4759  |  | ** <b>Summary:</b>  | 
4760  |  | ** <blockquote><table border=0 cellpadding=0 cellspacing=0>  | 
4761  |  | ** <tr><td><b>sqlite3_column_blob</b><td>→<td>BLOB result  | 
4762  |  | ** <tr><td><b>sqlite3_column_double</b><td>→<td>REAL result  | 
4763  |  | ** <tr><td><b>sqlite3_column_int</b><td>→<td>32-bit INTEGER result  | 
4764  |  | ** <tr><td><b>sqlite3_column_int64</b><td>→<td>64-bit INTEGER result  | 
4765  |  | ** <tr><td><b>sqlite3_column_text</b><td>→<td>UTF-8 TEXT result  | 
4766  |  | ** <tr><td><b>sqlite3_column_text16</b><td>→<td>UTF-16 TEXT result  | 
4767  |  | ** <tr><td><b>sqlite3_column_value</b><td>→<td>The result as an  | 
4768  |  | ** [sqlite3_value|unprotected sqlite3_value] object.  | 
4769  |  | ** <tr><td> <td> <td>   | 
4770  |  | ** <tr><td><b>sqlite3_column_bytes</b><td>→<td>Size of a BLOB  | 
4771  |  | ** or a UTF-8 TEXT result in bytes  | 
4772  |  | ** <tr><td><b>sqlite3_column_bytes16  </b>  | 
4773  |  | ** <td>→  <td>Size of UTF-16  | 
4774  |  | ** TEXT in bytes  | 
4775  |  | ** <tr><td><b>sqlite3_column_type</b><td>→<td>Default  | 
4776  |  | ** datatype of the result  | 
4777  |  | ** </table></blockquote>  | 
4778  |  | **  | 
4779  |  | ** <b>Details:</b>  | 
4780  |  | **  | 
4781  |  | ** ^These routines return information about a single column of the current  | 
4782  |  | ** result row of a query.  ^In every case the first argument is a pointer  | 
4783  |  | ** to the [prepared statement] that is being evaluated (the [sqlite3_stmt*]  | 
4784  |  | ** that was returned from [sqlite3_prepare_v2()] or one of its variants)  | 
4785  |  | ** and the second argument is the index of the column for which information  | 
4786  |  | ** should be returned. ^The leftmost column of the result set has the index 0.  | 
4787  |  | ** ^The number of columns in the result can be determined using  | 
4788  |  | ** [sqlite3_column_count()].  | 
4789  |  | **  | 
4790  |  | ** If the SQL statement does not currently point to a valid row, or if the  | 
4791  |  | ** column index is out of range, the result is undefined.  | 
4792  |  | ** These routines may only be called when the most recent call to  | 
4793  |  | ** [sqlite3_step()] has returned [SQLITE_ROW] and neither  | 
4794  |  | ** [sqlite3_reset()] nor [sqlite3_finalize()] have been called subsequently.  | 
4795  |  | ** If any of these routines are called after [sqlite3_reset()] or  | 
4796  |  | ** [sqlite3_finalize()] or after [sqlite3_step()] has returned  | 
4797  |  | ** something other than [SQLITE_ROW], the results are undefined.  | 
4798  |  | ** If [sqlite3_step()] or [sqlite3_reset()] or [sqlite3_finalize()]  | 
4799  |  | ** are called from a different thread while any of these routines  | 
4800  |  | ** are pending, then the results are undefined.  | 
4801  |  | **  | 
4802  |  | ** The first six interfaces (_blob, _double, _int, _int64, _text, and _text16)  | 
4803  |  | ** each return the value of a result column in a specific data format.  If  | 
4804  |  | ** the result column is not initially in the requested format (for example,  | 
4805  |  | ** if the query returns an integer but the sqlite3_column_text() interface  | 
4806  |  | ** is used to extract the value) then an automatic type conversion is performed.  | 
4807  |  | **  | 
4808  |  | ** ^The sqlite3_column_type() routine returns the  | 
4809  |  | ** [SQLITE_INTEGER | datatype code] for the initial data type  | 
4810  |  | ** of the result column.  ^The returned value is one of [SQLITE_INTEGER],  | 
4811  |  | ** [SQLITE_FLOAT], [SQLITE_TEXT], [SQLITE_BLOB], or [SQLITE_NULL].  | 
4812  |  | ** The return value of sqlite3_column_type() can be used to decide which  | 
4813  |  | ** of the first six interface should be used to extract the column value.  | 
4814  |  | ** The value returned by sqlite3_column_type() is only meaningful if no  | 
4815  |  | ** automatic type conversions have occurred for the value in question.  | 
4816  |  | ** After a type conversion, the result of calling sqlite3_column_type()  | 
4817  |  | ** is undefined, though harmless.  Future  | 
4818  |  | ** versions of SQLite may change the behavior of sqlite3_column_type()  | 
4819  |  | ** following a type conversion.  | 
4820  |  | **  | 
4821  |  | ** If the result is a BLOB or a TEXT string, then the sqlite3_column_bytes()  | 
4822  |  | ** or sqlite3_column_bytes16() interfaces can be used to determine the size  | 
4823  |  | ** of that BLOB or string.  | 
4824  |  | **  | 
4825  |  | ** ^If the result is a BLOB or UTF-8 string then the sqlite3_column_bytes()  | 
4826  |  | ** routine returns the number of bytes in that BLOB or string.  | 
4827  |  | ** ^If the result is a UTF-16 string, then sqlite3_column_bytes() converts  | 
4828  |  | ** the string to UTF-8 and then returns the number of bytes.  | 
4829  |  | ** ^If the result is a numeric value then sqlite3_column_bytes() uses  | 
4830  |  | ** [sqlite3_snprintf()] to convert that value to a UTF-8 string and returns  | 
4831  |  | ** the number of bytes in that string.  | 
4832  |  | ** ^If the result is NULL, then sqlite3_column_bytes() returns zero.  | 
4833  |  | **  | 
4834  |  | ** ^If the result is a BLOB or UTF-16 string then the sqlite3_column_bytes16()  | 
4835  |  | ** routine returns the number of bytes in that BLOB or string.  | 
4836  |  | ** ^If the result is a UTF-8 string, then sqlite3_column_bytes16() converts  | 
4837  |  | ** the string to UTF-16 and then returns the number of bytes.  | 
4838  |  | ** ^If the result is a numeric value then sqlite3_column_bytes16() uses  | 
4839  |  | ** [sqlite3_snprintf()] to convert that value to a UTF-16 string and returns  | 
4840  |  | ** the number of bytes in that string.  | 
4841  |  | ** ^If the result is NULL, then sqlite3_column_bytes16() returns zero.  | 
4842  |  | **  | 
4843  |  | ** ^The values returned by [sqlite3_column_bytes()] and  | 
4844  |  | ** [sqlite3_column_bytes16()] do not include the zero terminators at the end  | 
4845  |  | ** of the string.  ^For clarity: the values returned by  | 
4846  |  | ** [sqlite3_column_bytes()] and [sqlite3_column_bytes16()] are the number of  | 
4847  |  | ** bytes in the string, not the number of characters.  | 
4848  |  | **  | 
4849  |  | ** ^Strings returned by sqlite3_column_text() and sqlite3_column_text16(),  | 
4850  |  | ** even empty strings, are always zero-terminated.  ^The return  | 
4851  |  | ** value from sqlite3_column_blob() for a zero-length BLOB is a NULL pointer.  | 
4852  |  | **  | 
4853  |  | ** <b>Warning:</b> ^The object returned by [sqlite3_column_value()] is an  | 
4854  |  | ** [unprotected sqlite3_value] object.  In a multithreaded environment,  | 
4855  |  | ** an unprotected sqlite3_value object may only be used safely with  | 
4856  |  | ** [sqlite3_bind_value()] and [sqlite3_result_value()].  | 
4857  |  | ** If the [unprotected sqlite3_value] object returned by  | 
4858  |  | ** [sqlite3_column_value()] is used in any other way, including calls  | 
4859  |  | ** to routines like [sqlite3_value_int()], [sqlite3_value_text()],  | 
4860  |  | ** or [sqlite3_value_bytes()], the behavior is not threadsafe.  | 
4861  |  | ** Hence, the sqlite3_column_value() interface  | 
4862  |  | ** is normally only useful within the implementation of  | 
4863  |  | ** [application-defined SQL functions] or [virtual tables], not within  | 
4864  |  | ** top-level application code.  | 
4865  |  | **  | 
4866  |  | ** The these routines may attempt to convert the datatype of the result.  | 
4867  |  | ** ^For example, if the internal representation is FLOAT and a text result  | 
4868  |  | ** is requested, [sqlite3_snprintf()] is used internally to perform the  | 
4869  |  | ** conversion automatically.  ^(The following table details the conversions  | 
4870  |  | ** that are applied:  | 
4871  |  | **  | 
4872  |  | ** <blockquote>  | 
4873  |  | ** <table border="1">  | 
4874  |  | ** <tr><th> Internal<br>Type <th> Requested<br>Type <th>  Conversion  | 
4875  |  | **  | 
4876  |  | ** <tr><td>  NULL    <td> INTEGER   <td> Result is 0  | 
4877  |  | ** <tr><td>  NULL    <td>  FLOAT    <td> Result is 0.0  | 
4878  |  | ** <tr><td>  NULL    <td>   TEXT    <td> Result is a NULL pointer  | 
4879  |  | ** <tr><td>  NULL    <td>   BLOB    <td> Result is a NULL pointer  | 
4880  |  | ** <tr><td> INTEGER  <td>  FLOAT    <td> Convert from integer to float  | 
4881  |  | ** <tr><td> INTEGER  <td>   TEXT    <td> ASCII rendering of the integer  | 
4882  |  | ** <tr><td> INTEGER  <td>   BLOB    <td> Same as INTEGER->TEXT  | 
4883  |  | ** <tr><td>  FLOAT   <td> INTEGER   <td> [CAST] to INTEGER  | 
4884  |  | ** <tr><td>  FLOAT   <td>   TEXT    <td> ASCII rendering of the float  | 
4885  |  | ** <tr><td>  FLOAT   <td>   BLOB    <td> [CAST] to BLOB  | 
4886  |  | ** <tr><td>  TEXT    <td> INTEGER   <td> [CAST] to INTEGER  | 
4887  |  | ** <tr><td>  TEXT    <td>  FLOAT    <td> [CAST] to REAL  | 
4888  |  | ** <tr><td>  TEXT    <td>   BLOB    <td> No change  | 
4889  |  | ** <tr><td>  BLOB    <td> INTEGER   <td> [CAST] to INTEGER  | 
4890  |  | ** <tr><td>  BLOB    <td>  FLOAT    <td> [CAST] to REAL  | 
4891  |  | ** <tr><td>  BLOB    <td>   TEXT    <td> Add a zero terminator if needed  | 
4892  |  | ** </table>  | 
4893  |  | ** </blockquote>)^  | 
4894  |  | **  | 
4895  |  | ** Note that when type conversions occur, pointers returned by prior  | 
4896  |  | ** calls to sqlite3_column_blob(), sqlite3_column_text(), and/or  | 
4897  |  | ** sqlite3_column_text16() may be invalidated.  | 
4898  |  | ** Type conversions and pointer invalidations might occur  | 
4899  |  | ** in the following cases:  | 
4900  |  | **  | 
4901  |  | ** <ul>  | 
4902  |  | ** <li> The initial content is a BLOB and sqlite3_column_text() or  | 
4903  |  | **      sqlite3_column_text16() is called.  A zero-terminator might  | 
4904  |  | **      need to be added to the string.</li>  | 
4905  |  | ** <li> The initial content is UTF-8 text and sqlite3_column_bytes16() or  | 
4906  |  | **      sqlite3_column_text16() is called.  The content must be converted  | 
4907  |  | **      to UTF-16.</li>  | 
4908  |  | ** <li> The initial content is UTF-16 text and sqlite3_column_bytes() or  | 
4909  |  | **      sqlite3_column_text() is called.  The content must be converted  | 
4910  |  | **      to UTF-8.</li>  | 
4911  |  | ** </ul>  | 
4912  |  | **  | 
4913  |  | ** ^Conversions between UTF-16be and UTF-16le are always done in place and do  | 
4914  |  | ** not invalidate a prior pointer, though of course the content of the buffer  | 
4915  |  | ** that the prior pointer references will have been modified.  Other kinds  | 
4916  |  | ** of conversion are done in place when it is possible, but sometimes they  | 
4917  |  | ** are not possible and in those cases prior pointers are invalidated.  | 
4918  |  | **  | 
4919  |  | ** The safest policy is to invoke these routines  | 
4920  |  | ** in one of the following ways:  | 
4921  |  | **  | 
4922  |  | ** <ul>  | 
4923  |  | **  <li>sqlite3_column_text() followed by sqlite3_column_bytes()</li>  | 
4924  |  | **  <li>sqlite3_column_blob() followed by sqlite3_column_bytes()</li>  | 
4925  |  | **  <li>sqlite3_column_text16() followed by sqlite3_column_bytes16()</li>  | 
4926  |  | ** </ul>  | 
4927  |  | **  | 
4928  |  | ** In other words, you should call sqlite3_column_text(),  | 
4929  |  | ** sqlite3_column_blob(), or sqlite3_column_text16() first to force the result  | 
4930  |  | ** into the desired format, then invoke sqlite3_column_bytes() or  | 
4931  |  | ** sqlite3_column_bytes16() to find the size of the result.  Do not mix calls  | 
4932  |  | ** to sqlite3_column_text() or sqlite3_column_blob() with calls to  | 
4933  |  | ** sqlite3_column_bytes16(), and do not mix calls to sqlite3_column_text16()  | 
4934  |  | ** with calls to sqlite3_column_bytes().  | 
4935  |  | **  | 
4936  |  | ** ^The pointers returned are valid until a type conversion occurs as  | 
4937  |  | ** described above, or until [sqlite3_step()] or [sqlite3_reset()] or  | 
4938  |  | ** [sqlite3_finalize()] is called.  ^The memory space used to hold strings  | 
4939  |  | ** and BLOBs is freed automatically.  Do not pass the pointers returned  | 
4940  |  | ** from [sqlite3_column_blob()], [sqlite3_column_text()], etc. into  | 
4941  |  | ** [sqlite3_free()].  | 
4942  |  | **  | 
4943  |  | ** As long as the input parameters are correct, these routines will only  | 
4944  |  | ** fail if an out-of-memory error occurs during a format conversion.  | 
4945  |  | ** Only the following subset of interfaces are subject to out-of-memory  | 
4946  |  | ** errors:  | 
4947  |  | **  | 
4948  |  | ** <ul>  | 
4949  |  | ** <li> sqlite3_column_blob()  | 
4950  |  | ** <li> sqlite3_column_text()  | 
4951  |  | ** <li> sqlite3_column_text16()  | 
4952  |  | ** <li> sqlite3_column_bytes()  | 
4953  |  | ** <li> sqlite3_column_bytes16()  | 
4954  |  | ** </ul>  | 
4955  |  | **  | 
4956  |  | ** If an out-of-memory error occurs, then the return value from these  | 
4957  |  | ** routines is the same as if the column had contained an SQL NULL value.  | 
4958  |  | ** Valid SQL NULL returns can be distinguished from out-of-memory errors  | 
4959  |  | ** by invoking the [sqlite3_errcode()] immediately after the suspect  | 
4960  |  | ** return value is obtained and before any  | 
4961  |  | ** other SQLite interface is called on the same [database connection].  | 
4962  |  | */  | 
4963  |  | SQLITE_API const void *sqlite3_column_blob(sqlite3_stmt*, int iCol);  | 
4964  |  | SQLITE_API double sqlite3_column_double(sqlite3_stmt*, int iCol);  | 
4965  |  | SQLITE_API int sqlite3_column_int(sqlite3_stmt*, int iCol);  | 
4966  |  | SQLITE_API sqlite3_int64 sqlite3_column_int64(sqlite3_stmt*, int iCol);  | 
4967  |  | SQLITE_API const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);  | 
4968  |  | SQLITE_API const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);  | 
4969  |  | SQLITE_API sqlite3_value *sqlite3_column_value(sqlite3_stmt*, int iCol);  | 
4970  |  | SQLITE_API int sqlite3_column_bytes(sqlite3_stmt*, int iCol);  | 
4971  |  | SQLITE_API int sqlite3_column_bytes16(sqlite3_stmt*, int iCol);  | 
4972  |  | SQLITE_API int sqlite3_column_type(sqlite3_stmt*, int iCol);  | 
4973  |  |  | 
4974  |  | /*  | 
4975  |  | ** CAPI3REF: Destroy A Prepared Statement Object  | 
4976  |  | ** DESTRUCTOR: sqlite3_stmt  | 
4977  |  | **  | 
4978  |  | ** ^The sqlite3_finalize() function is called to delete a [prepared statement].  | 
4979  |  | ** ^If the most recent evaluation of the statement encountered no errors  | 
4980  |  | ** or if the statement is never been evaluated, then sqlite3_finalize() returns  | 
4981  |  | ** SQLITE_OK.  ^If the most recent evaluation of statement S failed, then  | 
4982  |  | ** sqlite3_finalize(S) returns the appropriate [error code] or  | 
4983  |  | ** [extended error code].  | 
4984  |  | **  | 
4985  |  | ** ^The sqlite3_finalize(S) routine can be called at any point during  | 
4986  |  | ** the life cycle of [prepared statement] S:  | 
4987  |  | ** before statement S is ever evaluated, after  | 
4988  |  | ** one or more calls to [sqlite3_reset()], or after any call  | 
4989  |  | ** to [sqlite3_step()] regardless of whether or not the statement has  | 
4990  |  | ** completed execution.  | 
4991  |  | **  | 
4992  |  | ** ^Invoking sqlite3_finalize() on a NULL pointer is a harmless no-op.  | 
4993  |  | **  | 
4994  |  | ** The application must finalize every [prepared statement] in order to avoid  | 
4995  |  | ** resource leaks.  It is a grievous error for the application to try to use  | 
4996  |  | ** a prepared statement after it has been finalized.  Any use of a prepared  | 
4997  |  | ** statement after it has been finalized can result in undefined and  | 
4998  |  | ** undesirable behavior such as segfaults and heap corruption.  | 
4999  |  | */  | 
5000  |  | SQLITE_API int sqlite3_finalize(sqlite3_stmt *pStmt);  | 
5001  |  |  | 
5002  |  | /*  | 
5003  |  | ** CAPI3REF: Reset A Prepared Statement Object  | 
5004  |  | ** METHOD: sqlite3_stmt  | 
5005  |  | **  | 
5006  |  | ** The sqlite3_reset() function is called to reset a [prepared statement]  | 
5007  |  | ** object back to its initial state, ready to be re-executed.  | 
5008  |  | ** ^Any SQL statement variables that had values bound to them using  | 
5009  |  | ** the [sqlite3_bind_blob | sqlite3_bind_*() API] retain their values.  | 
5010  |  | ** Use [sqlite3_clear_bindings()] to reset the bindings.  | 
5011  |  | **  | 
5012  |  | ** ^The [sqlite3_reset(S)] interface resets the [prepared statement] S  | 
5013  |  | ** back to the beginning of its program.  | 
5014  |  | **  | 
5015  |  | ** ^If the most recent call to [sqlite3_step(S)] for the  | 
5016  |  | ** [prepared statement] S returned [SQLITE_ROW] or [SQLITE_DONE],  | 
5017  |  | ** or if [sqlite3_step(S)] has never before been called on S,  | 
5018  |  | ** then [sqlite3_reset(S)] returns [SQLITE_OK].  | 
5019  |  | **  | 
5020  |  | ** ^If the most recent call to [sqlite3_step(S)] for the  | 
5021  |  | ** [prepared statement] S indicated an error, then  | 
5022  |  | ** [sqlite3_reset(S)] returns an appropriate [error code].  | 
5023  |  | **  | 
5024  |  | ** ^The [sqlite3_reset(S)] interface does not change the values  | 
5025  |  | ** of any [sqlite3_bind_blob|bindings] on the [prepared statement] S.  | 
5026  |  | */  | 
5027  |  | SQLITE_API int sqlite3_reset(sqlite3_stmt *pStmt);  | 
5028  |  |  | 
5029  |  | /*  | 
5030  |  | ** CAPI3REF: Create Or Redefine SQL Functions  | 
5031  |  | ** KEYWORDS: {function creation routines} | 
5032  |  | ** METHOD: sqlite3  | 
5033  |  | **  | 
5034  |  | ** ^These functions (collectively known as "function creation routines")  | 
5035  |  | ** are used to add SQL functions or aggregates or to redefine the behavior  | 
5036  |  | ** of existing SQL functions or aggregates. The only differences between  | 
5037  |  | ** the three "sqlite3_create_function*" routines are the text encoding  | 
5038  |  | ** expected for the second parameter (the name of the function being  | 
5039  |  | ** created) and the presence or absence of a destructor callback for  | 
5040  |  | ** the application data pointer. Function sqlite3_create_window_function()  | 
5041  |  | ** is similar, but allows the user to supply the extra callback functions  | 
5042  |  | ** needed by [aggregate window functions].  | 
5043  |  | **  | 
5044  |  | ** ^The first parameter is the [database connection] to which the SQL  | 
5045  |  | ** function is to be added.  ^If an application uses more than one database  | 
5046  |  | ** connection then application-defined SQL functions must be added  | 
5047  |  | ** to each database connection separately.  | 
5048  |  | **  | 
5049  |  | ** ^The second parameter is the name of the SQL function to be created or  | 
5050  |  | ** redefined.  ^The length of the name is limited to 255 bytes in a UTF-8  | 
5051  |  | ** representation, exclusive of the zero-terminator.  ^Note that the name  | 
5052  |  | ** length limit is in UTF-8 bytes, not characters nor UTF-16 bytes.  | 
5053  |  | ** ^Any attempt to create a function with a longer name  | 
5054  |  | ** will result in [SQLITE_MISUSE] being returned.  | 
5055  |  | **  | 
5056  |  | ** ^The third parameter (nArg)  | 
5057  |  | ** is the number of arguments that the SQL function or  | 
5058  |  | ** aggregate takes. ^If this parameter is -1, then the SQL function or  | 
5059  |  | ** aggregate may take any number of arguments between 0 and the limit  | 
5060  |  | ** set by [sqlite3_limit]([SQLITE_LIMIT_FUNCTION_ARG]).  If the third  | 
5061  |  | ** parameter is less than -1 or greater than 127 then the behavior is  | 
5062  |  | ** undefined.  | 
5063  |  | **  | 
5064  |  | ** ^The fourth parameter, eTextRep, specifies what  | 
5065  |  | ** [SQLITE_UTF8 | text encoding] this SQL function prefers for  | 
5066  |  | ** its parameters.  The application should set this parameter to  | 
5067  |  | ** [SQLITE_UTF16LE] if the function implementation invokes  | 
5068  |  | ** [sqlite3_value_text16le()] on an input, or [SQLITE_UTF16BE] if the  | 
5069  |  | ** implementation invokes [sqlite3_value_text16be()] on an input, or  | 
5070  |  | ** [SQLITE_UTF16] if [sqlite3_value_text16()] is used, or [SQLITE_UTF8]  | 
5071  |  | ** otherwise.  ^The same SQL function may be registered multiple times using  | 
5072  |  | ** different preferred text encodings, with different implementations for  | 
5073  |  | ** each encoding.  | 
5074  |  | ** ^When multiple implementations of the same function are available, SQLite  | 
5075  |  | ** will pick the one that involves the least amount of data conversion.  | 
5076  |  | **  | 
5077  |  | ** ^The fourth parameter may optionally be ORed with [SQLITE_DETERMINISTIC]  | 
5078  |  | ** to signal that the function will always return the same result given  | 
5079  |  | ** the same inputs within a single SQL statement.  Most SQL functions are  | 
5080  |  | ** deterministic.  The built-in [random()] SQL function is an example of a  | 
5081  |  | ** function that is not deterministic.  The SQLite query planner is able to  | 
5082  |  | ** perform additional optimizations on deterministic functions, so use  | 
5083  |  | ** of the [SQLITE_DETERMINISTIC] flag is recommended where possible.  | 
5084  |  | **  | 
5085  |  | ** ^The fourth parameter may also optionally include the [SQLITE_DIRECTONLY]  | 
5086  |  | ** flag, which if present prevents the function from being invoked from  | 
5087  |  | ** within VIEWs, TRIGGERs, CHECK constraints, generated column expressions,  | 
5088  |  | ** index expressions, or the WHERE clause of partial indexes.  | 
5089  |  | **  | 
5090  |  | ** <span style="background-color:#ffff90;">  | 
5091  |  | ** For best security, the [SQLITE_DIRECTONLY] flag is recommended for  | 
5092  |  | ** all application-defined SQL functions that do not need to be  | 
5093  |  | ** used inside of triggers, view, CHECK constraints, or other elements of  | 
5094  |  | ** the database schema.  This flags is especially recommended for SQL  | 
5095  |  | ** functions that have side effects or reveal internal application state.  | 
5096  |  | ** Without this flag, an attacker might be able to modify the schema of  | 
5097  |  | ** a database file to include invocations of the function with parameters  | 
5098  |  | ** chosen by the attacker, which the application will then execute when  | 
5099  |  | ** the database file is opened and read.  | 
5100  |  | ** </span>  | 
5101  |  | **  | 
5102  |  | ** ^(The fifth parameter is an arbitrary pointer.  The implementation of the  | 
5103  |  | ** function can gain access to this pointer using [sqlite3_user_data()].)^  | 
5104  |  | **  | 
5105  |  | ** ^The sixth, seventh and eighth parameters passed to the three  | 
5106  |  | ** "sqlite3_create_function*" functions, xFunc, xStep and xFinal, are  | 
5107  |  | ** pointers to C-language functions that implement the SQL function or  | 
5108  |  | ** aggregate. ^A scalar SQL function requires an implementation of the xFunc  | 
5109  |  | ** callback only; NULL pointers must be passed as the xStep and xFinal  | 
5110  |  | ** parameters. ^An aggregate SQL function requires an implementation of xStep  | 
5111  |  | ** and xFinal and NULL pointer must be passed for xFunc. ^To delete an existing  | 
5112  |  | ** SQL function or aggregate, pass NULL pointers for all three function  | 
5113  |  | ** callbacks.  | 
5114  |  | **  | 
5115  |  | ** ^The sixth, seventh, eighth and ninth parameters (xStep, xFinal, xValue  | 
5116  |  | ** and xInverse) passed to sqlite3_create_window_function are pointers to  | 
5117  |  | ** C-language callbacks that implement the new function. xStep and xFinal  | 
5118  |  | ** must both be non-NULL. xValue and xInverse may either both be NULL, in  | 
5119  |  | ** which case a regular aggregate function is created, or must both be  | 
5120  |  | ** non-NULL, in which case the new function may be used as either an aggregate  | 
5121  |  | ** or aggregate window function. More details regarding the implementation  | 
5122  |  | ** of aggregate window functions are  | 
5123  |  | ** [user-defined window functions|available here].  | 
5124  |  | **  | 
5125  |  | ** ^(If the final parameter to sqlite3_create_function_v2() or  | 
5126  |  | ** sqlite3_create_window_function() is not NULL, then it is destructor for  | 
5127  |  | ** the application data pointer. The destructor is invoked when the function  | 
5128  |  | ** is deleted, either by being overloaded or when the database connection  | 
5129  |  | ** closes.)^ ^The destructor is also invoked if the call to  | 
5130  |  | ** sqlite3_create_function_v2() fails.  ^When the destructor callback is  | 
5131  |  | ** invoked, it is passed a single argument which is a copy of the application  | 
5132  |  | ** data pointer which was the fifth parameter to sqlite3_create_function_v2().  | 
5133  |  | **  | 
5134  |  | ** ^It is permitted to register multiple implementations of the same  | 
5135  |  | ** functions with the same name but with either differing numbers of  | 
5136  |  | ** arguments or differing preferred text encodings.  ^SQLite will use  | 
5137  |  | ** the implementation that most closely matches the way in which the  | 
5138  |  | ** SQL function is used.  ^A function implementation with a non-negative  | 
5139  |  | ** nArg parameter is a better match than a function implementation with  | 
5140  |  | ** a negative nArg.  ^A function where the preferred text encoding  | 
5141  |  | ** matches the database encoding is a better  | 
5142  |  | ** match than a function where the encoding is different.  | 
5143  |  | ** ^A function where the encoding difference is between UTF16le and UTF16be  | 
5144  |  | ** is a closer match than a function where the encoding difference is  | 
5145  |  | ** between UTF8 and UTF16.  | 
5146  |  | **  | 
5147  |  | ** ^Built-in functions may be overloaded by new application-defined functions.  | 
5148  |  | **  | 
5149  |  | ** ^An application-defined function is permitted to call other  | 
5150  |  | ** SQLite interfaces.  However, such calls must not  | 
5151  |  | ** close the database connection nor finalize or reset the prepared  | 
5152  |  | ** statement in which the function is running.  | 
5153  |  | */  | 
5154  |  | SQLITE_API int sqlite3_create_function(  | 
5155  |  |   sqlite3 *db,  | 
5156  |  |   const char *zFunctionName,  | 
5157  |  |   int nArg,  | 
5158  |  |   int eTextRep,  | 
5159  |  |   void *pApp,  | 
5160  |  |   void (*xFunc)(sqlite3_context*,int,sqlite3_value**),  | 
5161  |  |   void (*xStep)(sqlite3_context*,int,sqlite3_value**),  | 
5162  |  |   void (*xFinal)(sqlite3_context*)  | 
5163  |  | );  | 
5164  |  | SQLITE_API int sqlite3_create_function16(  | 
5165  |  |   sqlite3 *db,  | 
5166  |  |   const void *zFunctionName,  | 
5167  |  |   int nArg,  | 
5168  |  |   int eTextRep,  | 
5169  |  |   void *pApp,  | 
5170  |  |   void (*xFunc)(sqlite3_context*,int,sqlite3_value**),  | 
5171  |  |   void (*xStep)(sqlite3_context*,int,sqlite3_value**),  | 
5172  |  |   void (*xFinal)(sqlite3_context*)  | 
5173  |  | );  | 
5174  |  | SQLITE_API int sqlite3_create_function_v2(  | 
5175  |  |   sqlite3 *db,  | 
5176  |  |   const char *zFunctionName,  | 
5177  |  |   int nArg,  | 
5178  |  |   int eTextRep,  | 
5179  |  |   void *pApp,  | 
5180  |  |   void (*xFunc)(sqlite3_context*,int,sqlite3_value**),  | 
5181  |  |   void (*xStep)(sqlite3_context*,int,sqlite3_value**),  | 
5182  |  |   void (*xFinal)(sqlite3_context*),  | 
5183  |  |   void(*xDestroy)(void*)  | 
5184  |  | );  | 
5185  |  | SQLITE_API int sqlite3_create_window_function(  | 
5186  |  |   sqlite3 *db,  | 
5187  |  |   const char *zFunctionName,  | 
5188  |  |   int nArg,  | 
5189  |  |   int eTextRep,  | 
5190  |  |   void *pApp,  | 
5191  |  |   void (*xStep)(sqlite3_context*,int,sqlite3_value**),  | 
5192  |  |   void (*xFinal)(sqlite3_context*),  | 
5193  |  |   void (*xValue)(sqlite3_context*),  | 
5194  |  |   void (*xInverse)(sqlite3_context*,int,sqlite3_value**),  | 
5195  |  |   void(*xDestroy)(void*)  | 
5196  |  | );  | 
5197  |  |  | 
5198  |  | /*  | 
5199  |  | ** CAPI3REF: Text Encodings  | 
5200  |  | **  | 
5201  |  | ** These constant define integer codes that represent the various  | 
5202  |  | ** text encodings supported by SQLite.  | 
5203  |  | */  | 
5204  |  | #define SQLITE_UTF8           1    /* IMP: R-37514-35566 */  | 
5205  |  | #define SQLITE_UTF16LE        2    /* IMP: R-03371-37637 */  | 
5206  |  | #define SQLITE_UTF16BE        3    /* IMP: R-51971-34154 */  | 
5207  |  | #define SQLITE_UTF16          4    /* Use native byte order */  | 
5208  |  | #define SQLITE_ANY            5    /* Deprecated */  | 
5209  |  | #define SQLITE_UTF16_ALIGNED  8    /* sqlite3_create_collation only */  | 
5210  |  |  | 
5211  |  | /*  | 
5212  |  | ** CAPI3REF: Function Flags  | 
5213  |  | **  | 
5214  |  | ** These constants may be ORed together with the  | 
5215  |  | ** [SQLITE_UTF8 | preferred text encoding] as the fourth argument  | 
5216  |  | ** to [sqlite3_create_function()], [sqlite3_create_function16()], or  | 
5217  |  | ** [sqlite3_create_function_v2()].  | 
5218  |  | **  | 
5219  |  | ** <dl>  | 
5220  |  | ** [[SQLITE_DETERMINISTIC]] <dt>SQLITE_DETERMINISTIC</dt><dd>  | 
5221  |  | ** The SQLITE_DETERMINISTIC flag means that the new function always gives  | 
5222  |  | ** the same output when the input parameters are the same.  | 
5223  |  | ** The [abs|abs() function] is deterministic, for example, but  | 
5224  |  | ** [randomblob|randomblob()] is not.  Functions must  | 
5225  |  | ** be deterministic in order to be used in certain contexts such as  | 
5226  |  | ** with the WHERE clause of [partial indexes] or in [generated columns].  | 
5227  |  | ** SQLite might also optimize deterministic functions by factoring them  | 
5228  |  | ** out of inner loops.  | 
5229  |  | ** </dd>  | 
5230  |  | **  | 
5231  |  | ** [[SQLITE_DIRECTONLY]] <dt>SQLITE_DIRECTONLY</dt><dd>  | 
5232  |  | ** The SQLITE_DIRECTONLY flag means that the function may only be invoked  | 
5233  |  | ** from top-level SQL, and cannot be used in VIEWs or TRIGGERs nor in  | 
5234  |  | ** schema structures such as [CHECK constraints], [DEFAULT clauses],  | 
5235  |  | ** [expression indexes], [partial indexes], or [generated columns].  | 
5236  |  | ** The SQLITE_DIRECTONLY flags is a security feature which is recommended  | 
5237  |  | ** for all [application-defined SQL functions], and especially for functions  | 
5238  |  | ** that have side-effects or that could potentially leak sensitive  | 
5239  |  | ** information.  | 
5240  |  | ** </dd>  | 
5241  |  | **  | 
5242  |  | ** [[SQLITE_INNOCUOUS]] <dt>SQLITE_INNOCUOUS</dt><dd>  | 
5243  |  | ** The SQLITE_INNOCUOUS flag means that the function is unlikely  | 
5244  |  | ** to cause problems even if misused.  An innocuous function should have  | 
5245  |  | ** no side effects and should not depend on any values other than its  | 
5246  |  | ** input parameters. The [abs|abs() function] is an example of an  | 
5247  |  | ** innocuous function.  | 
5248  |  | ** The [load_extension() SQL function] is not innocuous because of its  | 
5249  |  | ** side effects.  | 
5250  |  | ** <p> SQLITE_INNOCUOUS is similar to SQLITE_DETERMINISTIC, but is not  | 
5251  |  | ** exactly the same.  The [random|random() function] is an example of a  | 
5252  |  | ** function that is innocuous but not deterministic.  | 
5253  |  | ** <p>Some heightened security settings  | 
5254  |  | ** ([SQLITE_DBCONFIG_TRUSTED_SCHEMA] and [PRAGMA trusted_schema=OFF])  | 
5255  |  | ** disable the use of SQL functions inside views and triggers and in  | 
5256  |  | ** schema structures such as [CHECK constraints], [DEFAULT clauses],  | 
5257  |  | ** [expression indexes], [partial indexes], and [generated columns] unless  | 
5258  |  | ** the function is tagged with SQLITE_INNOCUOUS.  Most built-in functions  | 
5259  |  | ** are innocuous.  Developers are advised to avoid using the  | 
5260  |  | ** SQLITE_INNOCUOUS flag for application-defined functions unless the  | 
5261  |  | ** function has been carefully audited and found to be free of potentially  | 
5262  |  | ** security-adverse side-effects and information-leaks.  | 
5263  |  | ** </dd>  | 
5264  |  | **  | 
5265  |  | ** [[SQLITE_SUBTYPE]] <dt>SQLITE_SUBTYPE</dt><dd>  | 
5266  |  | ** The SQLITE_SUBTYPE flag indicates to SQLite that a function may call  | 
5267  |  | ** [sqlite3_value_subtype()] to inspect the sub-types of its arguments.  | 
5268  |  | ** Specifying this flag makes no difference for scalar or aggregate user  | 
5269  |  | ** functions. However, if it is not specified for a user-defined window  | 
5270  |  | ** function, then any sub-types belonging to arguments passed to the window  | 
5271  |  | ** function may be discarded before the window function is called (i.e.  | 
5272  |  | ** sqlite3_value_subtype() will always return 0).  | 
5273  |  | ** </dd>  | 
5274  |  | ** </dl>  | 
5275  |  | */  | 
5276  |  | #define SQLITE_DETERMINISTIC    0x000000800  | 
5277  |  | #define SQLITE_DIRECTONLY       0x000080000  | 
5278  |  | #define SQLITE_SUBTYPE          0x000100000  | 
5279  |  | #define SQLITE_INNOCUOUS        0x000200000  | 
5280  |  |  | 
5281  |  | /*  | 
5282  |  | ** CAPI3REF: Deprecated Functions  | 
5283  |  | ** DEPRECATED  | 
5284  |  | **  | 
5285  |  | ** These functions are [deprecated].  In order to maintain  | 
5286  |  | ** backwards compatibility with older code, these functions continue  | 
5287  |  | ** to be supported.  However, new applications should avoid  | 
5288  |  | ** the use of these functions.  To encourage programmers to avoid  | 
5289  |  | ** these functions, we will not explain what they do.  | 
5290  |  | */  | 
5291  |  | #ifndef SQLITE_OMIT_DEPRECATED  | 
5292  |  | SQLITE_API SQLITE_DEPRECATED int sqlite3_aggregate_count(sqlite3_context*);  | 
5293  |  | SQLITE_API SQLITE_DEPRECATED int sqlite3_expired(sqlite3_stmt*);  | 
5294  |  | SQLITE_API SQLITE_DEPRECATED int sqlite3_transfer_bindings(sqlite3_stmt*, sqlite3_stmt*);  | 
5295  |  | SQLITE_API SQLITE_DEPRECATED int sqlite3_global_recover(void);  | 
5296  |  | SQLITE_API SQLITE_DEPRECATED void sqlite3_thread_cleanup(void);  | 
5297  |  | SQLITE_API SQLITE_DEPRECATED int sqlite3_memory_alarm(void(*)(void*,sqlite3_int64,int),  | 
5298  |  |                       void*,sqlite3_int64);  | 
5299  |  | #endif  | 
5300  |  |  | 
5301  |  | /*  | 
5302  |  | ** CAPI3REF: Obtaining SQL Values  | 
5303  |  | ** METHOD: sqlite3_value  | 
5304  |  | **  | 
5305  |  | ** <b>Summary:</b>  | 
5306  |  | ** <blockquote><table border=0 cellpadding=0 cellspacing=0>  | 
5307  |  | ** <tr><td><b>sqlite3_value_blob</b><td>→<td>BLOB value  | 
5308  |  | ** <tr><td><b>sqlite3_value_double</b><td>→<td>REAL value  | 
5309  |  | ** <tr><td><b>sqlite3_value_int</b><td>→<td>32-bit INTEGER value  | 
5310  |  | ** <tr><td><b>sqlite3_value_int64</b><td>→<td>64-bit INTEGER value  | 
5311  |  | ** <tr><td><b>sqlite3_value_pointer</b><td>→<td>Pointer value  | 
5312  |  | ** <tr><td><b>sqlite3_value_text</b><td>→<td>UTF-8 TEXT value  | 
5313  |  | ** <tr><td><b>sqlite3_value_text16</b><td>→<td>UTF-16 TEXT value in  | 
5314  |  | ** the native byteorder  | 
5315  |  | ** <tr><td><b>sqlite3_value_text16be</b><td>→<td>UTF-16be TEXT value  | 
5316  |  | ** <tr><td><b>sqlite3_value_text16le</b><td>→<td>UTF-16le TEXT value  | 
5317  |  | ** <tr><td> <td> <td>   | 
5318  |  | ** <tr><td><b>sqlite3_value_bytes</b><td>→<td>Size of a BLOB  | 
5319  |  | ** or a UTF-8 TEXT in bytes  | 
5320  |  | ** <tr><td><b>sqlite3_value_bytes16  </b>  | 
5321  |  | ** <td>→  <td>Size of UTF-16  | 
5322  |  | ** TEXT in bytes  | 
5323  |  | ** <tr><td><b>sqlite3_value_type</b><td>→<td>Default  | 
5324  |  | ** datatype of the value  | 
5325  |  | ** <tr><td><b>sqlite3_value_numeric_type  </b>  | 
5326  |  | ** <td>→  <td>Best numeric datatype of the value  | 
5327  |  | ** <tr><td><b>sqlite3_value_nochange  </b>  | 
5328  |  | ** <td>→  <td>True if the column is unchanged in an UPDATE  | 
5329  |  | ** against a virtual table.  | 
5330  |  | ** <tr><td><b>sqlite3_value_frombind  </b>  | 
5331  |  | ** <td>→  <td>True if value originated from a [bound parameter]  | 
5332  |  | ** </table></blockquote>  | 
5333  |  | **  | 
5334  |  | ** <b>Details:</b>  | 
5335  |  | **  | 
5336  |  | ** These routines extract type, size, and content information from  | 
5337  |  | ** [protected sqlite3_value] objects.  Protected sqlite3_value objects  | 
5338  |  | ** are used to pass parameter information into the functions that  | 
5339  |  | ** implement [application-defined SQL functions] and [virtual tables].  | 
5340  |  | **  | 
5341  |  | ** These routines work only with [protected sqlite3_value] objects.  | 
5342  |  | ** Any attempt to use these routines on an [unprotected sqlite3_value]  | 
5343  |  | ** is not threadsafe.  | 
5344  |  | **  | 
5345  |  | ** ^These routines work just like the corresponding [column access functions]  | 
5346  |  | ** except that these routines take a single [protected sqlite3_value] object  | 
5347  |  | ** pointer instead of a [sqlite3_stmt*] pointer and an integer column number.  | 
5348  |  | **  | 
5349  |  | ** ^The sqlite3_value_text16() interface extracts a UTF-16 string  | 
5350  |  | ** in the native byte-order of the host machine.  ^The  | 
5351  |  | ** sqlite3_value_text16be() and sqlite3_value_text16le() interfaces  | 
5352  |  | ** extract UTF-16 strings as big-endian and little-endian respectively.  | 
5353  |  | **  | 
5354  |  | ** ^If [sqlite3_value] object V was initialized  | 
5355  |  | ** using [sqlite3_bind_pointer(S,I,P,X,D)] or [sqlite3_result_pointer(C,P,X,D)]  | 
5356  |  | ** and if X and Y are strings that compare equal according to strcmp(X,Y),  | 
5357  |  | ** then sqlite3_value_pointer(V,Y) will return the pointer P.  ^Otherwise,  | 
5358  |  | ** sqlite3_value_pointer(V,Y) returns a NULL. The sqlite3_bind_pointer()  | 
5359  |  | ** routine is part of the [pointer passing interface] added for SQLite 3.20.0.  | 
5360  |  | **  | 
5361  |  | ** ^(The sqlite3_value_type(V) interface returns the  | 
5362  |  | ** [SQLITE_INTEGER | datatype code] for the initial datatype of the  | 
5363  |  | ** [sqlite3_value] object V. The returned value is one of [SQLITE_INTEGER],  | 
5364  |  | ** [SQLITE_FLOAT], [SQLITE_TEXT], [SQLITE_BLOB], or [SQLITE_NULL].)^  | 
5365  |  | ** Other interfaces might change the datatype for an sqlite3_value object.  | 
5366  |  | ** For example, if the datatype is initially SQLITE_INTEGER and  | 
5367  |  | ** sqlite3_value_text(V) is called to extract a text value for that  | 
5368  |  | ** integer, then subsequent calls to sqlite3_value_type(V) might return  | 
5369  |  | ** SQLITE_TEXT.  Whether or not a persistent internal datatype conversion  | 
5370  |  | ** occurs is undefined and may change from one release of SQLite to the next.  | 
5371  |  | **  | 
5372  |  | ** ^(The sqlite3_value_numeric_type() interface attempts to apply  | 
5373  |  | ** numeric affinity to the value.  This means that an attempt is  | 
5374  |  | ** made to convert the value to an integer or floating point.  If  | 
5375  |  | ** such a conversion is possible without loss of information (in other  | 
5376  |  | ** words, if the value is a string that looks like a number)  | 
5377  |  | ** then the conversion is performed.  Otherwise no conversion occurs.  | 
5378  |  | ** The [SQLITE_INTEGER | datatype] after conversion is returned.)^  | 
5379  |  | **  | 
5380  |  | ** ^Within the [xUpdate] method of a [virtual table], the  | 
5381  |  | ** sqlite3_value_nochange(X) interface returns true if and only if  | 
5382  |  | ** the column corresponding to X is unchanged by the UPDATE operation  | 
5383  |  | ** that the xUpdate method call was invoked to implement and if  | 
5384  |  | ** and the prior [xColumn] method call that was invoked to extracted  | 
5385  |  | ** the value for that column returned without setting a result (probably  | 
5386  |  | ** because it queried [sqlite3_vtab_nochange()] and found that the column  | 
5387  |  | ** was unchanging).  ^Within an [xUpdate] method, any value for which  | 
5388  |  | ** sqlite3_value_nochange(X) is true will in all other respects appear  | 
5389  |  | ** to be a NULL value.  If sqlite3_value_nochange(X) is invoked anywhere other  | 
5390  |  | ** than within an [xUpdate] method call for an UPDATE statement, then  | 
5391  |  | ** the return value is arbitrary and meaningless.  | 
5392  |  | **  | 
5393  |  | ** ^The sqlite3_value_frombind(X) interface returns non-zero if the  | 
5394  |  | ** value X originated from one of the [sqlite3_bind_int|sqlite3_bind()]  | 
5395  |  | ** interfaces.  ^If X comes from an SQL literal value, or a table column,  | 
5396  |  | ** or an expression, then sqlite3_value_frombind(X) returns zero.  | 
5397  |  | **  | 
5398  |  | ** Please pay particular attention to the fact that the pointer returned  | 
5399  |  | ** from [sqlite3_value_blob()], [sqlite3_value_text()], or  | 
5400  |  | ** [sqlite3_value_text16()] can be invalidated by a subsequent call to  | 
5401  |  | ** [sqlite3_value_bytes()], [sqlite3_value_bytes16()], [sqlite3_value_text()],  | 
5402  |  | ** or [sqlite3_value_text16()].  | 
5403  |  | **  | 
5404  |  | ** These routines must be called from the same thread as  | 
5405  |  | ** the SQL function that supplied the [sqlite3_value*] parameters.  | 
5406  |  | **  | 
5407  |  | ** As long as the input parameter is correct, these routines can only  | 
5408  |  | ** fail if an out-of-memory error occurs during a format conversion.  | 
5409  |  | ** Only the following subset of interfaces are subject to out-of-memory  | 
5410  |  | ** errors:  | 
5411  |  | **  | 
5412  |  | ** <ul>  | 
5413  |  | ** <li> sqlite3_value_blob()  | 
5414  |  | ** <li> sqlite3_value_text()  | 
5415  |  | ** <li> sqlite3_value_text16()  | 
5416  |  | ** <li> sqlite3_value_text16le()  | 
5417  |  | ** <li> sqlite3_value_text16be()  | 
5418  |  | ** <li> sqlite3_value_bytes()  | 
5419  |  | ** <li> sqlite3_value_bytes16()  | 
5420  |  | ** </ul>  | 
5421  |  | **  | 
5422  |  | ** If an out-of-memory error occurs, then the return value from these  | 
5423  |  | ** routines is the same as if the column had contained an SQL NULL value.  | 
5424  |  | ** Valid SQL NULL returns can be distinguished from out-of-memory errors  | 
5425  |  | ** by invoking the [sqlite3_errcode()] immediately after the suspect  | 
5426  |  | ** return value is obtained and before any  | 
5427  |  | ** other SQLite interface is called on the same [database connection].  | 
5428  |  | */  | 
5429  |  | SQLITE_API const void *sqlite3_value_blob(sqlite3_value*);  | 
5430  |  | SQLITE_API double sqlite3_value_double(sqlite3_value*);  | 
5431  |  | SQLITE_API int sqlite3_value_int(sqlite3_value*);  | 
5432  |  | SQLITE_API sqlite3_int64 sqlite3_value_int64(sqlite3_value*);  | 
5433  |  | SQLITE_API void *sqlite3_value_pointer(sqlite3_value*, const char*);  | 
5434  |  | SQLITE_API const unsigned char *sqlite3_value_text(sqlite3_value*);  | 
5435  |  | SQLITE_API const void *sqlite3_value_text16(sqlite3_value*);  | 
5436  |  | SQLITE_API const void *sqlite3_value_text16le(sqlite3_value*);  | 
5437  |  | SQLITE_API const void *sqlite3_value_text16be(sqlite3_value*);  | 
5438  |  | SQLITE_API int sqlite3_value_bytes(sqlite3_value*);  | 
5439  |  | SQLITE_API int sqlite3_value_bytes16(sqlite3_value*);  | 
5440  |  | SQLITE_API int sqlite3_value_type(sqlite3_value*);  | 
5441  |  | SQLITE_API int sqlite3_value_numeric_type(sqlite3_value*);  | 
5442  |  | SQLITE_API int sqlite3_value_nochange(sqlite3_value*);  | 
5443  |  | SQLITE_API int sqlite3_value_frombind(sqlite3_value*);  | 
5444  |  |  | 
5445  |  | /*  | 
5446  |  | ** CAPI3REF: Finding The Subtype Of SQL Values  | 
5447  |  | ** METHOD: sqlite3_value  | 
5448  |  | **  | 
5449  |  | ** The sqlite3_value_subtype(V) function returns the subtype for  | 
5450  |  | ** an [application-defined SQL function] argument V.  The subtype  | 
5451  |  | ** information can be used to pass a limited amount of context from  | 
5452  |  | ** one SQL function to another.  Use the [sqlite3_result_subtype()]  | 
5453  |  | ** routine to set the subtype for the return value of an SQL function.  | 
5454  |  | */  | 
5455  |  | SQLITE_API unsigned int sqlite3_value_subtype(sqlite3_value*);  | 
5456  |  |  | 
5457  |  | /*  | 
5458  |  | ** CAPI3REF: Copy And Free SQL Values  | 
5459  |  | ** METHOD: sqlite3_value  | 
5460  |  | **  | 
5461  |  | ** ^The sqlite3_value_dup(V) interface makes a copy of the [sqlite3_value]  | 
5462  |  | ** object D and returns a pointer to that copy.  ^The [sqlite3_value] returned  | 
5463  |  | ** is a [protected sqlite3_value] object even if the input is not.  | 
5464  |  | ** ^The sqlite3_value_dup(V) interface returns NULL if V is NULL or if a  | 
5465  |  | ** memory allocation fails.  | 
5466  |  | **  | 
5467  |  | ** ^The sqlite3_value_free(V) interface frees an [sqlite3_value] object  | 
5468  |  | ** previously obtained from [sqlite3_value_dup()].  ^If V is a NULL pointer  | 
5469  |  | ** then sqlite3_value_free(V) is a harmless no-op.  | 
5470  |  | */  | 
5471  |  | SQLITE_API sqlite3_value *sqlite3_value_dup(const sqlite3_value*);  | 
5472  |  | SQLITE_API void sqlite3_value_free(sqlite3_value*);  | 
5473  |  |  | 
5474  |  | /*  | 
5475  |  | ** CAPI3REF: Obtain Aggregate Function Context  | 
5476  |  | ** METHOD: sqlite3_context  | 
5477  |  | **  | 
5478  |  | ** Implementations of aggregate SQL functions use this  | 
5479  |  | ** routine to allocate memory for storing their state.  | 
5480  |  | **  | 
5481  |  | ** ^The first time the sqlite3_aggregate_context(C,N) routine is called  | 
5482  |  | ** for a particular aggregate function, SQLite allocates  | 
5483  |  | ** N bytes of memory, zeroes out that memory, and returns a pointer  | 
5484  |  | ** to the new memory. ^On second and subsequent calls to  | 
5485  |  | ** sqlite3_aggregate_context() for the same aggregate function instance,  | 
5486  |  | ** the same buffer is returned.  Sqlite3_aggregate_context() is normally  | 
5487  |  | ** called once for each invocation of the xStep callback and then one  | 
5488  |  | ** last time when the xFinal callback is invoked.  ^(When no rows match  | 
5489  |  | ** an aggregate query, the xStep() callback of the aggregate function  | 
5490  |  | ** implementation is never called and xFinal() is called exactly once.  | 
5491  |  | ** In those cases, sqlite3_aggregate_context() might be called for the  | 
5492  |  | ** first time from within xFinal().)^  | 
5493  |  | **  | 
5494  |  | ** ^The sqlite3_aggregate_context(C,N) routine returns a NULL pointer  | 
5495  |  | ** when first called if N is less than or equal to zero or if a memory  | 
5496  |  | ** allocate error occurs.  | 
5497  |  | **  | 
5498  |  | ** ^(The amount of space allocated by sqlite3_aggregate_context(C,N) is  | 
5499  |  | ** determined by the N parameter on first successful call.  Changing the  | 
5500  |  | ** value of N in any subsequent call to sqlite3_aggregate_context() within  | 
5501  |  | ** the same aggregate function instance will not resize the memory  | 
5502  |  | ** allocation.)^  Within the xFinal callback, it is customary to set  | 
5503  |  | ** N=0 in calls to sqlite3_aggregate_context(C,N) so that no  | 
5504  |  | ** pointless memory allocations occur.  | 
5505  |  | **  | 
5506  |  | ** ^SQLite automatically frees the memory allocated by  | 
5507  |  | ** sqlite3_aggregate_context() when the aggregate query concludes.  | 
5508  |  | **  | 
5509  |  | ** The first parameter must be a copy of the  | 
5510  |  | ** [sqlite3_context | SQL function context] that is the first parameter  | 
5511  |  | ** to the xStep or xFinal callback routine that implements the aggregate  | 
5512  |  | ** function.  | 
5513  |  | **  | 
5514  |  | ** This routine must be called from the same thread in which  | 
5515  |  | ** the aggregate SQL function is running.  | 
5516  |  | */  | 
5517  |  | SQLITE_API void *sqlite3_aggregate_context(sqlite3_context*, int nBytes);  | 
5518  |  |  | 
5519  |  | /*  | 
5520  |  | ** CAPI3REF: User Data For Functions  | 
5521  |  | ** METHOD: sqlite3_context  | 
5522  |  | **  | 
5523  |  | ** ^The sqlite3_user_data() interface returns a copy of  | 
5524  |  | ** the pointer that was the pUserData parameter (the 5th parameter)  | 
5525  |  | ** of the [sqlite3_create_function()]  | 
5526  |  | ** and [sqlite3_create_function16()] routines that originally  | 
5527  |  | ** registered the application defined function.  | 
5528  |  | **  | 
5529  |  | ** This routine must be called from the same thread in which  | 
5530  |  | ** the application-defined function is running.  | 
5531  |  | */  | 
5532  |  | SQLITE_API void *sqlite3_user_data(sqlite3_context*);  | 
5533  |  |  | 
5534  |  | /*  | 
5535  |  | ** CAPI3REF: Database Connection For Functions  | 
5536  |  | ** METHOD: sqlite3_context  | 
5537  |  | **  | 
5538  |  | ** ^The sqlite3_context_db_handle() interface returns a copy of  | 
5539  |  | ** the pointer to the [database connection] (the 1st parameter)  | 
5540  |  | ** of the [sqlite3_create_function()]  | 
5541  |  | ** and [sqlite3_create_function16()] routines that originally  | 
5542  |  | ** registered the application defined function.  | 
5543  |  | */  | 
5544  |  | SQLITE_API sqlite3 *sqlite3_context_db_handle(sqlite3_context*);  | 
5545  |  |  | 
5546  |  | /*  | 
5547  |  | ** CAPI3REF: Function Auxiliary Data  | 
5548  |  | ** METHOD: sqlite3_context  | 
5549  |  | **  | 
5550  |  | ** These functions may be used by (non-aggregate) SQL functions to  | 
5551  |  | ** associate metadata with argument values. If the same value is passed to  | 
5552  |  | ** multiple invocations of the same SQL function during query execution, under  | 
5553  |  | ** some circumstances the associated metadata may be preserved.  An example  | 
5554  |  | ** of where this might be useful is in a regular-expression matching  | 
5555  |  | ** function. The compiled version of the regular expression can be stored as  | 
5556  |  | ** metadata associated with the pattern string.  | 
5557  |  | ** Then as long as the pattern string remains the same,  | 
5558  |  | ** the compiled regular expression can be reused on multiple  | 
5559  |  | ** invocations of the same function.  | 
5560  |  | **  | 
5561  |  | ** ^The sqlite3_get_auxdata(C,N) interface returns a pointer to the metadata  | 
5562  |  | ** associated by the sqlite3_set_auxdata(C,N,P,X) function with the Nth argument  | 
5563  |  | ** value to the application-defined function.  ^N is zero for the left-most  | 
5564  |  | ** function argument.  ^If there is no metadata  | 
5565  |  | ** associated with the function argument, the sqlite3_get_auxdata(C,N) interface  | 
5566  |  | ** returns a NULL pointer.  | 
5567  |  | **  | 
5568  |  | ** ^The sqlite3_set_auxdata(C,N,P,X) interface saves P as metadata for the N-th  | 
5569  |  | ** argument of the application-defined function.  ^Subsequent  | 
5570  |  | ** calls to sqlite3_get_auxdata(C,N) return P from the most recent  | 
5571  |  | ** sqlite3_set_auxdata(C,N,P,X) call if the metadata is still valid or  | 
5572  |  | ** NULL if the metadata has been discarded.  | 
5573  |  | ** ^After each call to sqlite3_set_auxdata(C,N,P,X) where X is not NULL,  | 
5574  |  | ** SQLite will invoke the destructor function X with parameter P exactly  | 
5575  |  | ** once, when the metadata is discarded.  | 
5576  |  | ** SQLite is free to discard the metadata at any time, including: <ul>  | 
5577  |  | ** <li> ^(when the corresponding function parameter changes)^, or  | 
5578  |  | ** <li> ^(when [sqlite3_reset()] or [sqlite3_finalize()] is called for the  | 
5579  |  | **      SQL statement)^, or  | 
5580  |  | ** <li> ^(when sqlite3_set_auxdata() is invoked again on the same  | 
5581  |  | **       parameter)^, or  | 
5582  |  | ** <li> ^(during the original sqlite3_set_auxdata() call when a memory  | 
5583  |  | **      allocation error occurs.)^ </ul>  | 
5584  |  | **  | 
5585  |  | ** Note the last bullet in particular.  The destructor X in  | 
5586  |  | ** sqlite3_set_auxdata(C,N,P,X) might be called immediately, before the  | 
5587  |  | ** sqlite3_set_auxdata() interface even returns.  Hence sqlite3_set_auxdata()  | 
5588  |  | ** should be called near the end of the function implementation and the  | 
5589  |  | ** function implementation should not make any use of P after  | 
5590  |  | ** sqlite3_set_auxdata() has been called.  | 
5591  |  | **  | 
5592  |  | ** ^(In practice, metadata is preserved between function calls for  | 
5593  |  | ** function parameters that are compile-time constants, including literal  | 
5594  |  | ** values and [parameters] and expressions composed from the same.)^  | 
5595  |  | **  | 
5596  |  | ** The value of the N parameter to these interfaces should be non-negative.  | 
5597  |  | ** Future enhancements may make use of negative N values to define new  | 
5598  |  | ** kinds of function caching behavior.  | 
5599  |  | **  | 
5600  |  | ** These routines must be called from the same thread in which  | 
5601  |  | ** the SQL function is running.  | 
5602  |  | */  | 
5603  |  | SQLITE_API void *sqlite3_get_auxdata(sqlite3_context*, int N);  | 
5604  |  | SQLITE_API void sqlite3_set_auxdata(sqlite3_context*, int N, void*, void (*)(void*));  | 
5605  |  |  | 
5606  |  |  | 
5607  |  | /*  | 
5608  |  | ** CAPI3REF: Constants Defining Special Destructor Behavior  | 
5609  |  | **  | 
5610  |  | ** These are special values for the destructor that is passed in as the  | 
5611  |  | ** final argument to routines like [sqlite3_result_blob()].  ^If the destructor  | 
5612  |  | ** argument is SQLITE_STATIC, it means that the content pointer is constant  | 
5613  |  | ** and will never change.  It does not need to be destroyed.  ^The  | 
5614  |  | ** SQLITE_TRANSIENT value means that the content will likely change in  | 
5615  |  | ** the near future and that SQLite should make its own private copy of  | 
5616  |  | ** the content before returning.  | 
5617  |  | **  | 
5618  |  | ** The typedef is necessary to work around problems in certain  | 
5619  |  | ** C++ compilers.  | 
5620  |  | */  | 
5621  |  | typedef void (*sqlite3_destructor_type)(void*);  | 
5622  |  | #define SQLITE_STATIC      ((sqlite3_destructor_type)0)  | 
5623  |  | #define SQLITE_TRANSIENT   ((sqlite3_destructor_type)-1)  | 
5624  |  |  | 
5625  |  | /*  | 
5626  |  | ** CAPI3REF: Setting The Result Of An SQL Function  | 
5627  |  | ** METHOD: sqlite3_context  | 
5628  |  | **  | 
5629  |  | ** These routines are used by the xFunc or xFinal callbacks that  | 
5630  |  | ** implement SQL functions and aggregates.  See  | 
5631  |  | ** [sqlite3_create_function()] and [sqlite3_create_function16()]  | 
5632  |  | ** for additional information.  | 
5633  |  | **  | 
5634  |  | ** These functions work very much like the [parameter binding] family of  | 
5635  |  | ** functions used to bind values to host parameters in prepared statements.  | 
5636  |  | ** Refer to the [SQL parameter] documentation for additional information.  | 
5637  |  | **  | 
5638  |  | ** ^The sqlite3_result_blob() interface sets the result from  | 
5639  |  | ** an application-defined function to be the BLOB whose content is pointed  | 
5640  |  | ** to by the second parameter and which is N bytes long where N is the  | 
5641  |  | ** third parameter.  | 
5642  |  | **  | 
5643  |  | ** ^The sqlite3_result_zeroblob(C,N) and sqlite3_result_zeroblob64(C,N)  | 
5644  |  | ** interfaces set the result of the application-defined function to be  | 
5645  |  | ** a BLOB containing all zero bytes and N bytes in size.  | 
5646  |  | **  | 
5647  |  | ** ^The sqlite3_result_double() interface sets the result from  | 
5648  |  | ** an application-defined function to be a floating point value specified  | 
5649  |  | ** by its 2nd argument.  | 
5650  |  | **  | 
5651  |  | ** ^The sqlite3_result_error() and sqlite3_result_error16() functions  | 
5652  |  | ** cause the implemented SQL function to throw an exception.  | 
5653  |  | ** ^SQLite uses the string pointed to by the  | 
5654  |  | ** 2nd parameter of sqlite3_result_error() or sqlite3_result_error16()  | 
5655  |  | ** as the text of an error message.  ^SQLite interprets the error  | 
5656  |  | ** message string from sqlite3_result_error() as UTF-8. ^SQLite  | 
5657  |  | ** interprets the string from sqlite3_result_error16() as UTF-16 using  | 
5658  |  | ** the same [byte-order determination rules] as [sqlite3_bind_text16()].  | 
5659  |  | ** ^If the third parameter to sqlite3_result_error()  | 
5660  |  | ** or sqlite3_result_error16() is negative then SQLite takes as the error  | 
5661  |  | ** message all text up through the first zero character.  | 
5662  |  | ** ^If the third parameter to sqlite3_result_error() or  | 
5663  |  | ** sqlite3_result_error16() is non-negative then SQLite takes that many  | 
5664  |  | ** bytes (not characters) from the 2nd parameter as the error message.  | 
5665  |  | ** ^The sqlite3_result_error() and sqlite3_result_error16()  | 
5666  |  | ** routines make a private copy of the error message text before  | 
5667  |  | ** they return.  Hence, the calling function can deallocate or  | 
5668  |  | ** modify the text after they return without harm.  | 
5669  |  | ** ^The sqlite3_result_error_code() function changes the error code  | 
5670  |  | ** returned by SQLite as a result of an error in a function.  ^By default,  | 
5671  |  | ** the error code is SQLITE_ERROR.  ^A subsequent call to sqlite3_result_error()  | 
5672  |  | ** or sqlite3_result_error16() resets the error code to SQLITE_ERROR.  | 
5673  |  | **  | 
5674  |  | ** ^The sqlite3_result_error_toobig() interface causes SQLite to throw an  | 
5675  |  | ** error indicating that a string or BLOB is too long to represent.  | 
5676  |  | **  | 
5677  |  | ** ^The sqlite3_result_error_nomem() interface causes SQLite to throw an  | 
5678  |  | ** error indicating that a memory allocation failed.  | 
5679  |  | **  | 
5680  |  | ** ^The sqlite3_result_int() interface sets the return value  | 
5681  |  | ** of the application-defined function to be the 32-bit signed integer  | 
5682  |  | ** value given in the 2nd argument.  | 
5683  |  | ** ^The sqlite3_result_int64() interface sets the return value  | 
5684  |  | ** of the application-defined function to be the 64-bit signed integer  | 
5685  |  | ** value given in the 2nd argument.  | 
5686  |  | **  | 
5687  |  | ** ^The sqlite3_result_null() interface sets the return value  | 
5688  |  | ** of the application-defined function to be NULL.  | 
5689  |  | **  | 
5690  |  | ** ^The sqlite3_result_text(), sqlite3_result_text16(),  | 
5691  |  | ** sqlite3_result_text16le(), and sqlite3_result_text16be() interfaces  | 
5692  |  | ** set the return value of the application-defined function to be  | 
5693  |  | ** a text string which is represented as UTF-8, UTF-16 native byte order,  | 
5694  |  | ** UTF-16 little endian, or UTF-16 big endian, respectively.  | 
5695  |  | ** ^The sqlite3_result_text64() interface sets the return value of an  | 
5696  |  | ** application-defined function to be a text string in an encoding  | 
5697  |  | ** specified by the fifth (and last) parameter, which must be one  | 
5698  |  | ** of [SQLITE_UTF8], [SQLITE_UTF16], [SQLITE_UTF16BE], or [SQLITE_UTF16LE].  | 
5699  |  | ** ^SQLite takes the text result from the application from  | 
5700  |  | ** the 2nd parameter of the sqlite3_result_text* interfaces.  | 
5701  |  | ** ^If the 3rd parameter to the sqlite3_result_text* interfaces  | 
5702  |  | ** is negative, then SQLite takes result text from the 2nd parameter  | 
5703  |  | ** through the first zero character.  | 
5704  |  | ** ^If the 3rd parameter to the sqlite3_result_text* interfaces  | 
5705  |  | ** is non-negative, then as many bytes (not characters) of the text  | 
5706  |  | ** pointed to by the 2nd parameter are taken as the application-defined  | 
5707  |  | ** function result.  If the 3rd parameter is non-negative, then it  | 
5708  |  | ** must be the byte offset into the string where the NUL terminator would  | 
5709  |  | ** appear if the string where NUL terminated.  If any NUL characters occur  | 
5710  |  | ** in the string at a byte offset that is less than the value of the 3rd  | 
5711  |  | ** parameter, then the resulting string will contain embedded NULs and the  | 
5712  |  | ** result of expressions operating on strings with embedded NULs is undefined.  | 
5713  |  | ** ^If the 4th parameter to the sqlite3_result_text* interfaces  | 
5714  |  | ** or sqlite3_result_blob is a non-NULL pointer, then SQLite calls that  | 
5715  |  | ** function as the destructor on the text or BLOB result when it has  | 
5716  |  | ** finished using that result.  | 
5717  |  | ** ^If the 4th parameter to the sqlite3_result_text* interfaces or to  | 
5718  |  | ** sqlite3_result_blob is the special constant SQLITE_STATIC, then SQLite  | 
5719  |  | ** assumes that the text or BLOB result is in constant space and does not  | 
5720  |  | ** copy the content of the parameter nor call a destructor on the content  | 
5721  |  | ** when it has finished using that result.  | 
5722  |  | ** ^If the 4th parameter to the sqlite3_result_text* interfaces  | 
5723  |  | ** or sqlite3_result_blob is the special constant SQLITE_TRANSIENT  | 
5724  |  | ** then SQLite makes a copy of the result into space obtained  | 
5725  |  | ** from [sqlite3_malloc()] before it returns.  | 
5726  |  | **  | 
5727  |  | ** ^For the sqlite3_result_text16(), sqlite3_result_text16le(), and  | 
5728  |  | ** sqlite3_result_text16be() routines, and for sqlite3_result_text64()  | 
5729  |  | ** when the encoding is not UTF8, if the input UTF16 begins with a  | 
5730  |  | ** byte-order mark (BOM, U+FEFF) then the BOM is removed from the  | 
5731  |  | ** string and the rest of the string is interpreted according to the  | 
5732  |  | ** byte-order specified by the BOM.  ^The byte-order specified by  | 
5733  |  | ** the BOM at the beginning of the text overrides the byte-order  | 
5734  |  | ** specified by the interface procedure.  ^So, for example, if  | 
5735  |  | ** sqlite3_result_text16le() is invoked with text that begins  | 
5736  |  | ** with bytes 0xfe, 0xff (a big-endian byte-order mark) then the  | 
5737  |  | ** first two bytes of input are skipped and the remaining input  | 
5738  |  | ** is interpreted as UTF16BE text.  | 
5739  |  | **  | 
5740  |  | ** ^For UTF16 input text to the sqlite3_result_text16(),  | 
5741  |  | ** sqlite3_result_text16be(), sqlite3_result_text16le(), and  | 
5742  |  | ** sqlite3_result_text64() routines, if the text contains invalid  | 
5743  |  | ** UTF16 characters, the invalid characters might be converted  | 
5744  |  | ** into the unicode replacement character, U+FFFD.  | 
5745  |  | **  | 
5746  |  | ** ^The sqlite3_result_value() interface sets the result of  | 
5747  |  | ** the application-defined function to be a copy of the  | 
5748  |  | ** [unprotected sqlite3_value] object specified by the 2nd parameter.  ^The  | 
5749  |  | ** sqlite3_result_value() interface makes a copy of the [sqlite3_value]  | 
5750  |  | ** so that the [sqlite3_value] specified in the parameter may change or  | 
5751  |  | ** be deallocated after sqlite3_result_value() returns without harm.  | 
5752  |  | ** ^A [protected sqlite3_value] object may always be used where an  | 
5753  |  | ** [unprotected sqlite3_value] object is required, so either  | 
5754  |  | ** kind of [sqlite3_value] object can be used with this interface.  | 
5755  |  | **  | 
5756  |  | ** ^The sqlite3_result_pointer(C,P,T,D) interface sets the result to an  | 
5757  |  | ** SQL NULL value, just like [sqlite3_result_null(C)], except that it  | 
5758  |  | ** also associates the host-language pointer P or type T with that  | 
5759  |  | ** NULL value such that the pointer can be retrieved within an  | 
5760  |  | ** [application-defined SQL function] using [sqlite3_value_pointer()].  | 
5761  |  | ** ^If the D parameter is not NULL, then it is a pointer to a destructor  | 
5762  |  | ** for the P parameter.  ^SQLite invokes D with P as its only argument  | 
5763  |  | ** when SQLite is finished with P.  The T parameter should be a static  | 
5764  |  | ** string and preferably a string literal. The sqlite3_result_pointer()  | 
5765  |  | ** routine is part of the [pointer passing interface] added for SQLite 3.20.0.  | 
5766  |  | **  | 
5767  |  | ** If these routines are called from within the different thread  | 
5768  |  | ** than the one containing the application-defined function that received  | 
5769  |  | ** the [sqlite3_context] pointer, the results are undefined.  | 
5770  |  | */  | 
5771  |  | SQLITE_API void sqlite3_result_blob(sqlite3_context*, const void*, int, void(*)(void*));  | 
5772  |  | SQLITE_API void sqlite3_result_blob64(sqlite3_context*,const void*,  | 
5773  |  |                            sqlite3_uint64,void(*)(void*));  | 
5774  |  | SQLITE_API void sqlite3_result_double(sqlite3_context*, double);  | 
5775  |  | SQLITE_API void sqlite3_result_error(sqlite3_context*, const char*, int);  | 
5776  |  | SQLITE_API void sqlite3_result_error16(sqlite3_context*, const void*, int);  | 
5777  |  | SQLITE_API void sqlite3_result_error_toobig(sqlite3_context*);  | 
5778  |  | SQLITE_API void sqlite3_result_error_nomem(sqlite3_context*);  | 
5779  |  | SQLITE_API void sqlite3_result_error_code(sqlite3_context*, int);  | 
5780  |  | SQLITE_API void sqlite3_result_int(sqlite3_context*, int);  | 
5781  |  | SQLITE_API void sqlite3_result_int64(sqlite3_context*, sqlite3_int64);  | 
5782  |  | SQLITE_API void sqlite3_result_null(sqlite3_context*);  | 
5783  |  | SQLITE_API void sqlite3_result_text(sqlite3_context*, const char*, int, void(*)(void*));  | 
5784  |  | SQLITE_API void sqlite3_result_text64(sqlite3_context*, const char*,sqlite3_uint64,  | 
5785  |  |                            void(*)(void*), unsigned char encoding);  | 
5786  |  | SQLITE_API void sqlite3_result_text16(sqlite3_context*, const void*, int, void(*)(void*));  | 
5787  |  | SQLITE_API void sqlite3_result_text16le(sqlite3_context*, const void*, int,void(*)(void*));  | 
5788  |  | SQLITE_API void sqlite3_result_text16be(sqlite3_context*, const void*, int,void(*)(void*));  | 
5789  |  | SQLITE_API void sqlite3_result_value(sqlite3_context*, sqlite3_value*);  | 
5790  |  | SQLITE_API void sqlite3_result_pointer(sqlite3_context*, void*,const char*,void(*)(void*));  | 
5791  |  | SQLITE_API void sqlite3_result_zeroblob(sqlite3_context*, int n);  | 
5792  |  | SQLITE_API int sqlite3_result_zeroblob64(sqlite3_context*, sqlite3_uint64 n);  | 
5793  |  |  | 
5794  |  |  | 
5795  |  | /*  | 
5796  |  | ** CAPI3REF: Setting The Subtype Of An SQL Function  | 
5797  |  | ** METHOD: sqlite3_context  | 
5798  |  | **  | 
5799  |  | ** The sqlite3_result_subtype(C,T) function causes the subtype of  | 
5800  |  | ** the result from the [application-defined SQL function] with  | 
5801  |  | ** [sqlite3_context] C to be the value T.  Only the lower 8 bits  | 
5802  |  | ** of the subtype T are preserved in current versions of SQLite;  | 
5803  |  | ** higher order bits are discarded.  | 
5804  |  | ** The number of subtype bytes preserved by SQLite might increase  | 
5805  |  | ** in future releases of SQLite.  | 
5806  |  | */  | 
5807  |  | SQLITE_API void sqlite3_result_subtype(sqlite3_context*,unsigned int);  | 
5808  |  |  | 
5809  |  | /*  | 
5810  |  | ** CAPI3REF: Define New Collating Sequences  | 
5811  |  | ** METHOD: sqlite3  | 
5812  |  | **  | 
5813  |  | ** ^These functions add, remove, or modify a [collation] associated  | 
5814  |  | ** with the [database connection] specified as the first argument.  | 
5815  |  | **  | 
5816  |  | ** ^The name of the collation is a UTF-8 string  | 
5817  |  | ** for sqlite3_create_collation() and sqlite3_create_collation_v2()  | 
5818  |  | ** and a UTF-16 string in native byte order for sqlite3_create_collation16().  | 
5819  |  | ** ^Collation names that compare equal according to [sqlite3_strnicmp()] are  | 
5820  |  | ** considered to be the same name.  | 
5821  |  | **  | 
5822  |  | ** ^(The third argument (eTextRep) must be one of the constants:  | 
5823  |  | ** <ul>  | 
5824  |  | ** <li> [SQLITE_UTF8],  | 
5825  |  | ** <li> [SQLITE_UTF16LE],  | 
5826  |  | ** <li> [SQLITE_UTF16BE],  | 
5827  |  | ** <li> [SQLITE_UTF16], or  | 
5828  |  | ** <li> [SQLITE_UTF16_ALIGNED].  | 
5829  |  | ** </ul>)^  | 
5830  |  | ** ^The eTextRep argument determines the encoding of strings passed  | 
5831  |  | ** to the collating function callback, xCompare.  | 
5832  |  | ** ^The [SQLITE_UTF16] and [SQLITE_UTF16_ALIGNED] values for eTextRep  | 
5833  |  | ** force strings to be UTF16 with native byte order.  | 
5834  |  | ** ^The [SQLITE_UTF16_ALIGNED] value for eTextRep forces strings to begin  | 
5835  |  | ** on an even byte address.  | 
5836  |  | **  | 
5837  |  | ** ^The fourth argument, pArg, is an application data pointer that is passed  | 
5838  |  | ** through as the first argument to the collating function callback.  | 
5839  |  | **  | 
5840  |  | ** ^The fifth argument, xCompare, is a pointer to the collating function.  | 
5841  |  | ** ^Multiple collating functions can be registered using the same name but  | 
5842  |  | ** with different eTextRep parameters and SQLite will use whichever  | 
5843  |  | ** function requires the least amount of data transformation.  | 
5844  |  | ** ^If the xCompare argument is NULL then the collating function is  | 
5845  |  | ** deleted.  ^When all collating functions having the same name are deleted,  | 
5846  |  | ** that collation is no longer usable.  | 
5847  |  | **  | 
5848  |  | ** ^The collating function callback is invoked with a copy of the pArg  | 
5849  |  | ** application data pointer and with two strings in the encoding specified  | 
5850  |  | ** by the eTextRep argument.  The two integer parameters to the collating  | 
5851  |  | ** function callback are the length of the two strings, in bytes. The collating  | 
5852  |  | ** function must return an integer that is negative, zero, or positive  | 
5853  |  | ** if the first string is less than, equal to, or greater than the second,  | 
5854  |  | ** respectively.  A collating function must always return the same answer  | 
5855  |  | ** given the same inputs.  If two or more collating functions are registered  | 
5856  |  | ** to the same collation name (using different eTextRep values) then all  | 
5857  |  | ** must give an equivalent answer when invoked with equivalent strings.  | 
5858  |  | ** The collating function must obey the following properties for all  | 
5859  |  | ** strings A, B, and C:  | 
5860  |  | **  | 
5861  |  | ** <ol>  | 
5862  |  | ** <li> If A==B then B==A.  | 
5863  |  | ** <li> If A==B and B==C then A==C.  | 
5864  |  | ** <li> If A<B THEN B>A.  | 
5865  |  | ** <li> If A<B and B<C then A<C.  | 
5866  |  | ** </ol>  | 
5867  |  | **  | 
5868  |  | ** If a collating function fails any of the above constraints and that  | 
5869  |  | ** collating function is registered and used, then the behavior of SQLite  | 
5870  |  | ** is undefined.  | 
5871  |  | **  | 
5872  |  | ** ^The sqlite3_create_collation_v2() works like sqlite3_create_collation()  | 
5873  |  | ** with the addition that the xDestroy callback is invoked on pArg when  | 
5874  |  | ** the collating function is deleted.  | 
5875  |  | ** ^Collating functions are deleted when they are overridden by later  | 
5876  |  | ** calls to the collation creation functions or when the  | 
5877  |  | ** [database connection] is closed using [sqlite3_close()].  | 
5878  |  | **  | 
5879  |  | ** ^The xDestroy callback is <u>not</u> called if the  | 
5880  |  | ** sqlite3_create_collation_v2() function fails.  Applications that invoke  | 
5881  |  | ** sqlite3_create_collation_v2() with a non-NULL xDestroy argument should  | 
5882  |  | ** check the return code and dispose of the application data pointer  | 
5883  |  | ** themselves rather than expecting SQLite to deal with it for them.  | 
5884  |  | ** This is different from every other SQLite interface.  The inconsistency  | 
5885  |  | ** is unfortunate but cannot be changed without breaking backwards  | 
5886  |  | ** compatibility.  | 
5887  |  | **  | 
5888  |  | ** See also:  [sqlite3_collation_needed()] and [sqlite3_collation_needed16()].  | 
5889  |  | */  | 
5890  |  | SQLITE_API int sqlite3_create_collation(  | 
5891  |  |   sqlite3*,  | 
5892  |  |   const char *zName,  | 
5893  |  |   int eTextRep,  | 
5894  |  |   void *pArg,  | 
5895  |  |   int(*xCompare)(void*,int,const void*,int,const void*)  | 
5896  |  | );  | 
5897  |  | SQLITE_API int sqlite3_create_collation_v2(  | 
5898  |  |   sqlite3*,  | 
5899  |  |   const char *zName,  | 
5900  |  |   int eTextRep,  | 
5901  |  |   void *pArg,  | 
5902  |  |   int(*xCompare)(void*,int,const void*,int,const void*),  | 
5903  |  |   void(*xDestroy)(void*)  | 
5904  |  | );  | 
5905  |  | SQLITE_API int sqlite3_create_collation16(  | 
5906  |  |   sqlite3*,  | 
5907  |  |   const void *zName,  | 
5908  |  |   int eTextRep,  | 
5909  |  |   void *pArg,  | 
5910  |  |   int(*xCompare)(void*,int,const void*,int,const void*)  | 
5911  |  | );  | 
5912  |  |  | 
5913  |  | /*  | 
5914  |  | ** CAPI3REF: Collation Needed Callbacks  | 
5915  |  | ** METHOD: sqlite3  | 
5916  |  | **  | 
5917  |  | ** ^To avoid having to register all collation sequences before a database  | 
5918  |  | ** can be used, a single callback function may be registered with the  | 
5919  |  | ** [database connection] to be invoked whenever an undefined collation  | 
5920  |  | ** sequence is required.  | 
5921  |  | **  | 
5922  |  | ** ^If the function is registered using the sqlite3_collation_needed() API,  | 
5923  |  | ** then it is passed the names of undefined collation sequences as strings  | 
5924  |  | ** encoded in UTF-8. ^If sqlite3_collation_needed16() is used,  | 
5925  |  | ** the names are passed as UTF-16 in machine native byte order.  | 
5926  |  | ** ^A call to either function replaces the existing collation-needed callback.  | 
5927  |  | **  | 
5928  |  | ** ^(When the callback is invoked, the first argument passed is a copy  | 
5929  |  | ** of the second argument to sqlite3_collation_needed() or  | 
5930  |  | ** sqlite3_collation_needed16().  The second argument is the database  | 
5931  |  | ** connection.  The third argument is one of [SQLITE_UTF8], [SQLITE_UTF16BE],  | 
5932  |  | ** or [SQLITE_UTF16LE], indicating the most desirable form of the collation  | 
5933  |  | ** sequence function required.  The fourth parameter is the name of the  | 
5934  |  | ** required collation sequence.)^  | 
5935  |  | **  | 
5936  |  | ** The callback function should register the desired collation using  | 
5937  |  | ** [sqlite3_create_collation()], [sqlite3_create_collation16()], or  | 
5938  |  | ** [sqlite3_create_collation_v2()].  | 
5939  |  | */  | 
5940  |  | SQLITE_API int sqlite3_collation_needed(  | 
5941  |  |   sqlite3*,  | 
5942  |  |   void*,  | 
5943  |  |   void(*)(void*,sqlite3*,int eTextRep,const char*)  | 
5944  |  | );  | 
5945  |  | SQLITE_API int sqlite3_collation_needed16(  | 
5946  |  |   sqlite3*,  | 
5947  |  |   void*,  | 
5948  |  |   void(*)(void*,sqlite3*,int eTextRep,const void*)  | 
5949  |  | );  | 
5950  |  |  | 
5951  |  | #ifdef SQLITE_ENABLE_CEROD  | 
5952  |  | /*  | 
5953  |  | ** Specify the activation key for a CEROD database.  Unless  | 
5954  |  | ** activated, none of the CEROD routines will work.  | 
5955  |  | */  | 
5956  |  | SQLITE_API void sqlite3_activate_cerod(  | 
5957  |  |   const char *zPassPhrase        /* Activation phrase */  | 
5958  |  | );  | 
5959  |  | #endif  | 
5960  |  |  | 
5961  |  | /*  | 
5962  |  | ** CAPI3REF: Suspend Execution For A Short Time  | 
5963  |  | **  | 
5964  |  | ** The sqlite3_sleep() function causes the current thread to suspend execution  | 
5965  |  | ** for at least a number of milliseconds specified in its parameter.  | 
5966  |  | **  | 
5967  |  | ** If the operating system does not support sleep requests with  | 
5968  |  | ** millisecond time resolution, then the time will be rounded up to  | 
5969  |  | ** the nearest second. The number of milliseconds of sleep actually  | 
5970  |  | ** requested from the operating system is returned.  | 
5971  |  | **  | 
5972  |  | ** ^SQLite implements this interface by calling the xSleep()  | 
5973  |  | ** method of the default [sqlite3_vfs] object.  If the xSleep() method  | 
5974  |  | ** of the default VFS is not implemented correctly, or not implemented at  | 
5975  |  | ** all, then the behavior of sqlite3_sleep() may deviate from the description  | 
5976  |  | ** in the previous paragraphs.  | 
5977  |  | */  | 
5978  |  | SQLITE_API int sqlite3_sleep(int);  | 
5979  |  |  | 
5980  |  | /*  | 
5981  |  | ** CAPI3REF: Name Of The Folder Holding Temporary Files  | 
5982  |  | **  | 
5983  |  | ** ^(If this global variable is made to point to a string which is  | 
5984  |  | ** the name of a folder (a.k.a. directory), then all temporary files  | 
5985  |  | ** created by SQLite when using a built-in [sqlite3_vfs | VFS]  | 
5986  |  | ** will be placed in that directory.)^  ^If this variable  | 
5987  |  | ** is a NULL pointer, then SQLite performs a search for an appropriate  | 
5988  |  | ** temporary file directory.  | 
5989  |  | **  | 
5990  |  | ** Applications are strongly discouraged from using this global variable.  | 
5991  |  | ** It is required to set a temporary folder on Windows Runtime (WinRT).  | 
5992  |  | ** But for all other platforms, it is highly recommended that applications  | 
5993  |  | ** neither read nor write this variable.  This global variable is a relic  | 
5994  |  | ** that exists for backwards compatibility of legacy applications and should  | 
5995  |  | ** be avoided in new projects.  | 
5996  |  | **  | 
5997  |  | ** It is not safe to read or modify this variable in more than one  | 
5998  |  | ** thread at a time.  It is not safe to read or modify this variable  | 
5999  |  | ** if a [database connection] is being used at the same time in a separate  | 
6000  |  | ** thread.  | 
6001  |  | ** It is intended that this variable be set once  | 
6002  |  | ** as part of process initialization and before any SQLite interface  | 
6003  |  | ** routines have been called and that this variable remain unchanged  | 
6004  |  | ** thereafter.  | 
6005  |  | **  | 
6006  |  | ** ^The [temp_store_directory pragma] may modify this variable and cause  | 
6007  |  | ** it to point to memory obtained from [sqlite3_malloc].  ^Furthermore,  | 
6008  |  | ** the [temp_store_directory pragma] always assumes that any string  | 
6009  |  | ** that this variable points to is held in memory obtained from  | 
6010  |  | ** [sqlite3_malloc] and the pragma may attempt to free that memory  | 
6011  |  | ** using [sqlite3_free].  | 
6012  |  | ** Hence, if this variable is modified directly, either it should be  | 
6013  |  | ** made NULL or made to point to memory obtained from [sqlite3_malloc]  | 
6014  |  | ** or else the use of the [temp_store_directory pragma] should be avoided.  | 
6015  |  | ** Except when requested by the [temp_store_directory pragma], SQLite  | 
6016  |  | ** does not free the memory that sqlite3_temp_directory points to.  If  | 
6017  |  | ** the application wants that memory to be freed, it must do  | 
6018  |  | ** so itself, taking care to only do so after all [database connection]  | 
6019  |  | ** objects have been destroyed.  | 
6020  |  | **  | 
6021  |  | ** <b>Note to Windows Runtime users:</b>  The temporary directory must be set  | 
6022  |  | ** prior to calling [sqlite3_open] or [sqlite3_open_v2].  Otherwise, various  | 
6023  |  | ** features that require the use of temporary files may fail.  Here is an  | 
6024  |  | ** example of how to do this using C++ with the Windows Runtime:  | 
6025  |  | **  | 
6026  |  | ** <blockquote><pre>  | 
6027  |  | ** LPCWSTR zPath = Windows::Storage::ApplicationData::Current->  | 
6028  |  | **       TemporaryFolder->Path->Data();  | 
6029  |  | ** char zPathBuf[MAX_PATH + 1];  | 
6030  |  | ** memset(zPathBuf, 0, sizeof(zPathBuf));  | 
6031  |  | ** WideCharToMultiByte(CP_UTF8, 0, zPath, -1, zPathBuf, sizeof(zPathBuf),  | 
6032  |  | **       NULL, NULL);  | 
6033  |  | ** sqlite3_temp_directory = sqlite3_mprintf("%s", zPathBuf); | 
6034  |  | ** </pre></blockquote>  | 
6035  |  | */  | 
6036  |  | SQLITE_API SQLITE_EXTERN char *sqlite3_temp_directory;  | 
6037  |  |  | 
6038  |  | /*  | 
6039  |  | ** CAPI3REF: Name Of The Folder Holding Database Files  | 
6040  |  | **  | 
6041  |  | ** ^(If this global variable is made to point to a string which is  | 
6042  |  | ** the name of a folder (a.k.a. directory), then all database files  | 
6043  |  | ** specified with a relative pathname and created or accessed by  | 
6044  |  | ** SQLite when using a built-in windows [sqlite3_vfs | VFS] will be assumed  | 
6045  |  | ** to be relative to that directory.)^ ^If this variable is a NULL  | 
6046  |  | ** pointer, then SQLite assumes that all database files specified  | 
6047  |  | ** with a relative pathname are relative to the current directory  | 
6048  |  | ** for the process.  Only the windows VFS makes use of this global  | 
6049  |  | ** variable; it is ignored by the unix VFS.  | 
6050  |  | **  | 
6051  |  | ** Changing the value of this variable while a database connection is  | 
6052  |  | ** open can result in a corrupt database.  | 
6053  |  | **  | 
6054  |  | ** It is not safe to read or modify this variable in more than one  | 
6055  |  | ** thread at a time.  It is not safe to read or modify this variable  | 
6056  |  | ** if a [database connection] is being used at the same time in a separate  | 
6057  |  | ** thread.  | 
6058  |  | ** It is intended that this variable be set once  | 
6059  |  | ** as part of process initialization and before any SQLite interface  | 
6060  |  | ** routines have been called and that this variable remain unchanged  | 
6061  |  | ** thereafter.  | 
6062  |  | **  | 
6063  |  | ** ^The [data_store_directory pragma] may modify this variable and cause  | 
6064  |  | ** it to point to memory obtained from [sqlite3_malloc].  ^Furthermore,  | 
6065  |  | ** the [data_store_directory pragma] always assumes that any string  | 
6066  |  | ** that this variable points to is held in memory obtained from  | 
6067  |  | ** [sqlite3_malloc] and the pragma may attempt to free that memory  | 
6068  |  | ** using [sqlite3_free].  | 
6069  |  | ** Hence, if this variable is modified directly, either it should be  | 
6070  |  | ** made NULL or made to point to memory obtained from [sqlite3_malloc]  | 
6071  |  | ** or else the use of the [data_store_directory pragma] should be avoided.  | 
6072  |  | */  | 
6073  |  | SQLITE_API SQLITE_EXTERN char *sqlite3_data_directory;  | 
6074  |  |  | 
6075  |  | /*  | 
6076  |  | ** CAPI3REF: Win32 Specific Interface  | 
6077  |  | **  | 
6078  |  | ** These interfaces are available only on Windows.  The  | 
6079  |  | ** [sqlite3_win32_set_directory] interface is used to set the value associated  | 
6080  |  | ** with the [sqlite3_temp_directory] or [sqlite3_data_directory] variable, to  | 
6081  |  | ** zValue, depending on the value of the type parameter.  The zValue parameter  | 
6082  |  | ** should be NULL to cause the previous value to be freed via [sqlite3_free];  | 
6083  |  | ** a non-NULL value will be copied into memory obtained from [sqlite3_malloc]  | 
6084  |  | ** prior to being used.  The [sqlite3_win32_set_directory] interface returns  | 
6085  |  | ** [SQLITE_OK] to indicate success, [SQLITE_ERROR] if the type is unsupported,  | 
6086  |  | ** or [SQLITE_NOMEM] if memory could not be allocated.  The value of the  | 
6087  |  | ** [sqlite3_data_directory] variable is intended to act as a replacement for  | 
6088  |  | ** the current directory on the sub-platforms of Win32 where that concept is  | 
6089  |  | ** not present, e.g. WinRT and UWP.  The [sqlite3_win32_set_directory8] and  | 
6090  |  | ** [sqlite3_win32_set_directory16] interfaces behave exactly the same as the  | 
6091  |  | ** sqlite3_win32_set_directory interface except the string parameter must be  | 
6092  |  | ** UTF-8 or UTF-16, respectively.  | 
6093  |  | */  | 
6094  |  | SQLITE_API int sqlite3_win32_set_directory(  | 
6095  |  |   unsigned long type, /* Identifier for directory being set or reset */  | 
6096  |  |   void *zValue        /* New value for directory being set or reset */  | 
6097  |  | );  | 
6098  |  | SQLITE_API int sqlite3_win32_set_directory8(unsigned long type, const char *zValue);  | 
6099  |  | SQLITE_API int sqlite3_win32_set_directory16(unsigned long type, const void *zValue);  | 
6100  |  |  | 
6101  |  | /*  | 
6102  |  | ** CAPI3REF: Win32 Directory Types  | 
6103  |  | **  | 
6104  |  | ** These macros are only available on Windows.  They define the allowed values  | 
6105  |  | ** for the type argument to the [sqlite3_win32_set_directory] interface.  | 
6106  |  | */  | 
6107  |  | #define SQLITE_WIN32_DATA_DIRECTORY_TYPE  1  | 
6108  |  | #define SQLITE_WIN32_TEMP_DIRECTORY_TYPE  2  | 
6109  |  |  | 
6110  |  | /*  | 
6111  |  | ** CAPI3REF: Test For Auto-Commit Mode  | 
6112  |  | ** KEYWORDS: {autocommit mode} | 
6113  |  | ** METHOD: sqlite3  | 
6114  |  | **  | 
6115  |  | ** ^The sqlite3_get_autocommit() interface returns non-zero or  | 
6116  |  | ** zero if the given database connection is or is not in autocommit mode,  | 
6117  |  | ** respectively.  ^Autocommit mode is on by default.  | 
6118  |  | ** ^Autocommit mode is disabled by a [BEGIN] statement.  | 
6119  |  | ** ^Autocommit mode is re-enabled by a [COMMIT] or [ROLLBACK].  | 
6120  |  | **  | 
6121  |  | ** If certain kinds of errors occur on a statement within a multi-statement  | 
6122  |  | ** transaction (errors including [SQLITE_FULL], [SQLITE_IOERR],  | 
6123  |  | ** [SQLITE_NOMEM], [SQLITE_BUSY], and [SQLITE_INTERRUPT]) then the  | 
6124  |  | ** transaction might be rolled back automatically.  The only way to  | 
6125  |  | ** find out whether SQLite automatically rolled back the transaction after  | 
6126  |  | ** an error is to use this function.  | 
6127  |  | **  | 
6128  |  | ** If another thread changes the autocommit status of the database  | 
6129  |  | ** connection while this routine is running, then the return value  | 
6130  |  | ** is undefined.  | 
6131  |  | */  | 
6132  |  | SQLITE_API int sqlite3_get_autocommit(sqlite3*);  | 
6133  |  |  | 
6134  |  | /*  | 
6135  |  | ** CAPI3REF: Find The Database Handle Of A Prepared Statement  | 
6136  |  | ** METHOD: sqlite3_stmt  | 
6137  |  | **  | 
6138  |  | ** ^The sqlite3_db_handle interface returns the [database connection] handle  | 
6139  |  | ** to which a [prepared statement] belongs.  ^The [database connection]  | 
6140  |  | ** returned by sqlite3_db_handle is the same [database connection]  | 
6141  |  | ** that was the first argument  | 
6142  |  | ** to the [sqlite3_prepare_v2()] call (or its variants) that was used to  | 
6143  |  | ** create the statement in the first place.  | 
6144  |  | */  | 
6145  |  | SQLITE_API sqlite3 *sqlite3_db_handle(sqlite3_stmt*);  | 
6146  |  |  | 
6147  |  | /*  | 
6148  |  | ** CAPI3REF: Return The Filename For A Database Connection  | 
6149  |  | ** METHOD: sqlite3  | 
6150  |  | **  | 
6151  |  | ** ^The sqlite3_db_filename(D,N) interface returns a pointer to the filename  | 
6152  |  | ** associated with database N of connection D.  | 
6153  |  | ** ^If there is no attached database N on the database  | 
6154  |  | ** connection D, or if database N is a temporary or in-memory database, then  | 
6155  |  | ** this function will return either a NULL pointer or an empty string.  | 
6156  |  | **  | 
6157  |  | ** ^The string value returned by this routine is owned and managed by  | 
6158  |  | ** the database connection.  ^The value will be valid until the database N  | 
6159  |  | ** is [DETACH]-ed or until the database connection closes.  | 
6160  |  | **  | 
6161  |  | ** ^The filename returned by this function is the output of the  | 
6162  |  | ** xFullPathname method of the [VFS].  ^In other words, the filename  | 
6163  |  | ** will be an absolute pathname, even if the filename used  | 
6164  |  | ** to open the database originally was a URI or relative pathname.  | 
6165  |  | **  | 
6166  |  | ** If the filename pointer returned by this routine is not NULL, then it  | 
6167  |  | ** can be used as the filename input parameter to these routines:  | 
6168  |  | ** <ul>  | 
6169  |  | ** <li> [sqlite3_uri_parameter()]  | 
6170  |  | ** <li> [sqlite3_uri_boolean()]  | 
6171  |  | ** <li> [sqlite3_uri_int64()]  | 
6172  |  | ** <li> [sqlite3_filename_database()]  | 
6173  |  | ** <li> [sqlite3_filename_journal()]  | 
6174  |  | ** <li> [sqlite3_filename_wal()]  | 
6175  |  | ** </ul>  | 
6176  |  | */  | 
6177  |  | SQLITE_API const char *sqlite3_db_filename(sqlite3 *db, const char *zDbName);  | 
6178  |  |  | 
6179  |  | /*  | 
6180  |  | ** CAPI3REF: Determine if a database is read-only  | 
6181  |  | ** METHOD: sqlite3  | 
6182  |  | **  | 
6183  |  | ** ^The sqlite3_db_readonly(D,N) interface returns 1 if the database N  | 
6184  |  | ** of connection D is read-only, 0 if it is read/write, or -1 if N is not  | 
6185  |  | ** the name of a database on connection D.  | 
6186  |  | */  | 
6187  |  | SQLITE_API int sqlite3_db_readonly(sqlite3 *db, const char *zDbName);  | 
6188  |  |  | 
6189  |  | /*  | 
6190  |  | ** CAPI3REF: Find the next prepared statement  | 
6191  |  | ** METHOD: sqlite3  | 
6192  |  | **  | 
6193  |  | ** ^This interface returns a pointer to the next [prepared statement] after  | 
6194  |  | ** pStmt associated with the [database connection] pDb.  ^If pStmt is NULL  | 
6195  |  | ** then this interface returns a pointer to the first prepared statement  | 
6196  |  | ** associated with the database connection pDb.  ^If no prepared statement  | 
6197  |  | ** satisfies the conditions of this routine, it returns NULL.  | 
6198  |  | **  | 
6199  |  | ** The [database connection] pointer D in a call to  | 
6200  |  | ** [sqlite3_next_stmt(D,S)] must refer to an open database  | 
6201  |  | ** connection and in particular must not be a NULL pointer.  | 
6202  |  | */  | 
6203  |  | SQLITE_API sqlite3_stmt *sqlite3_next_stmt(sqlite3 *pDb, sqlite3_stmt *pStmt);  | 
6204  |  |  | 
6205  |  | /*  | 
6206  |  | ** CAPI3REF: Commit And Rollback Notification Callbacks  | 
6207  |  | ** METHOD: sqlite3  | 
6208  |  | **  | 
6209  |  | ** ^The sqlite3_commit_hook() interface registers a callback  | 
6210  |  | ** function to be invoked whenever a transaction is [COMMIT | committed].  | 
6211  |  | ** ^Any callback set by a previous call to sqlite3_commit_hook()  | 
6212  |  | ** for the same database connection is overridden.  | 
6213  |  | ** ^The sqlite3_rollback_hook() interface registers a callback  | 
6214  |  | ** function to be invoked whenever a transaction is [ROLLBACK | rolled back].  | 
6215  |  | ** ^Any callback set by a previous call to sqlite3_rollback_hook()  | 
6216  |  | ** for the same database connection is overridden.  | 
6217  |  | ** ^The pArg argument is passed through to the callback.  | 
6218  |  | ** ^If the callback on a commit hook function returns non-zero,  | 
6219  |  | ** then the commit is converted into a rollback.  | 
6220  |  | **  | 
6221  |  | ** ^The sqlite3_commit_hook(D,C,P) and sqlite3_rollback_hook(D,C,P) functions  | 
6222  |  | ** return the P argument from the previous call of the same function  | 
6223  |  | ** on the same [database connection] D, or NULL for  | 
6224  |  | ** the first call for each function on D.  | 
6225  |  | **  | 
6226  |  | ** The commit and rollback hook callbacks are not reentrant.  | 
6227  |  | ** The callback implementation must not do anything that will modify  | 
6228  |  | ** the database connection that invoked the callback.  Any actions  | 
6229  |  | ** to modify the database connection must be deferred until after the  | 
6230  |  | ** completion of the [sqlite3_step()] call that triggered the commit  | 
6231  |  | ** or rollback hook in the first place.  | 
6232  |  | ** Note that running any other SQL statements, including SELECT statements,  | 
6233  |  | ** or merely calling [sqlite3_prepare_v2()] and [sqlite3_step()] will modify  | 
6234  |  | ** the database connections for the meaning of "modify" in this paragraph.  | 
6235  |  | **  | 
6236  |  | ** ^Registering a NULL function disables the callback.  | 
6237  |  | **  | 
6238  |  | ** ^When the commit hook callback routine returns zero, the [COMMIT]  | 
6239  |  | ** operation is allowed to continue normally.  ^If the commit hook  | 
6240  |  | ** returns non-zero, then the [COMMIT] is converted into a [ROLLBACK].  | 
6241  |  | ** ^The rollback hook is invoked on a rollback that results from a commit  | 
6242  |  | ** hook returning non-zero, just as it would be with any other rollback.  | 
6243  |  | **  | 
6244  |  | ** ^For the purposes of this API, a transaction is said to have been  | 
6245  |  | ** rolled back if an explicit "ROLLBACK" statement is executed, or  | 
6246  |  | ** an error or constraint causes an implicit rollback to occur.  | 
6247  |  | ** ^The rollback callback is not invoked if a transaction is  | 
6248  |  | ** automatically rolled back because the database connection is closed.  | 
6249  |  | **  | 
6250  |  | ** See also the [sqlite3_update_hook()] interface.  | 
6251  |  | */  | 
6252  |  | SQLITE_API void *sqlite3_commit_hook(sqlite3*, int(*)(void*), void*);  | 
6253  |  | SQLITE_API void *sqlite3_rollback_hook(sqlite3*, void(*)(void *), void*);  | 
6254  |  |  | 
6255  |  | /*  | 
6256  |  | ** CAPI3REF: Data Change Notification Callbacks  | 
6257  |  | ** METHOD: sqlite3  | 
6258  |  | **  | 
6259  |  | ** ^The sqlite3_update_hook() interface registers a callback function  | 
6260  |  | ** with the [database connection] identified by the first argument  | 
6261  |  | ** to be invoked whenever a row is updated, inserted or deleted in  | 
6262  |  | ** a [rowid table].  | 
6263  |  | ** ^Any callback set by a previous call to this function  | 
6264  |  | ** for the same database connection is overridden.  | 
6265  |  | **  | 
6266  |  | ** ^The second argument is a pointer to the function to invoke when a  | 
6267  |  | ** row is updated, inserted or deleted in a rowid table.  | 
6268  |  | ** ^The first argument to the callback is a copy of the third argument  | 
6269  |  | ** to sqlite3_update_hook().  | 
6270  |  | ** ^The second callback argument is one of [SQLITE_INSERT], [SQLITE_DELETE],  | 
6271  |  | ** or [SQLITE_UPDATE], depending on the operation that caused the callback  | 
6272  |  | ** to be invoked.  | 
6273  |  | ** ^The third and fourth arguments to the callback contain pointers to the  | 
6274  |  | ** database and table name containing the affected row.  | 
6275  |  | ** ^The final callback parameter is the [rowid] of the row.  | 
6276  |  | ** ^In the case of an update, this is the [rowid] after the update takes place.  | 
6277  |  | **  | 
6278  |  | ** ^(The update hook is not invoked when internal system tables are  | 
6279  |  | ** modified (i.e. sqlite_sequence).)^  | 
6280  |  | ** ^The update hook is not invoked when [WITHOUT ROWID] tables are modified.  | 
6281  |  | **  | 
6282  |  | ** ^In the current implementation, the update hook  | 
6283  |  | ** is not invoked when conflicting rows are deleted because of an  | 
6284  |  | ** [ON CONFLICT | ON CONFLICT REPLACE] clause.  ^Nor is the update hook  | 
6285  |  | ** invoked when rows are deleted using the [truncate optimization].  | 
6286  |  | ** The exceptions defined in this paragraph might change in a future  | 
6287  |  | ** release of SQLite.  | 
6288  |  | **  | 
6289  |  | ** The update hook implementation must not do anything that will modify  | 
6290  |  | ** the database connection that invoked the update hook.  Any actions  | 
6291  |  | ** to modify the database connection must be deferred until after the  | 
6292  |  | ** completion of the [sqlite3_step()] call that triggered the update hook.  | 
6293  |  | ** Note that [sqlite3_prepare_v2()] and [sqlite3_step()] both modify their  | 
6294  |  | ** database connections for the meaning of "modify" in this paragraph.  | 
6295  |  | **  | 
6296  |  | ** ^The sqlite3_update_hook(D,C,P) function  | 
6297  |  | ** returns the P argument from the previous call  | 
6298  |  | ** on the same [database connection] D, or NULL for  | 
6299  |  | ** the first call on D.  | 
6300  |  | **  | 
6301  |  | ** See also the [sqlite3_commit_hook()], [sqlite3_rollback_hook()],  | 
6302  |  | ** and [sqlite3_preupdate_hook()] interfaces.  | 
6303  |  | */  | 
6304  |  | SQLITE_API void *sqlite3_update_hook(  | 
6305  |  |   sqlite3*,  | 
6306  |  |   void(*)(void *,int ,char const *,char const *,sqlite3_int64),  | 
6307  |  |   void*  | 
6308  |  | );  | 
6309  |  |  | 
6310  |  | /*  | 
6311  |  | ** CAPI3REF: Enable Or Disable Shared Pager Cache  | 
6312  |  | **  | 
6313  |  | ** ^(This routine enables or disables the sharing of the database cache  | 
6314  |  | ** and schema data structures between [database connection | connections]  | 
6315  |  | ** to the same database. Sharing is enabled if the argument is true  | 
6316  |  | ** and disabled if the argument is false.)^  | 
6317  |  | **  | 
6318  |  | ** ^Cache sharing is enabled and disabled for an entire process.  | 
6319  |  | ** This is a change as of SQLite [version 3.5.0] ([dateof:3.5.0]).  | 
6320  |  | ** In prior versions of SQLite,  | 
6321  |  | ** sharing was enabled or disabled for each thread separately.  | 
6322  |  | **  | 
6323  |  | ** ^(The cache sharing mode set by this interface effects all subsequent  | 
6324  |  | ** calls to [sqlite3_open()], [sqlite3_open_v2()], and [sqlite3_open16()].  | 
6325  |  | ** Existing database connections continue to use the sharing mode  | 
6326  |  | ** that was in effect at the time they were opened.)^  | 
6327  |  | **  | 
6328  |  | ** ^(This routine returns [SQLITE_OK] if shared cache was enabled or disabled  | 
6329  |  | ** successfully.  An [error code] is returned otherwise.)^  | 
6330  |  | **  | 
6331  |  | ** ^Shared cache is disabled by default. It is recommended that it stay  | 
6332  |  | ** that way.  In other words, do not use this routine.  This interface  | 
6333  |  | ** continues to be provided for historical compatibility, but its use is  | 
6334  |  | ** discouraged.  Any use of shared cache is discouraged.  If shared cache  | 
6335  |  | ** must be used, it is recommended that shared cache only be enabled for  | 
6336  |  | ** individual database connections using the [sqlite3_open_v2()] interface  | 
6337  |  | ** with the [SQLITE_OPEN_SHAREDCACHE] flag.  | 
6338  |  | **  | 
6339  |  | ** Note: This method is disabled on MacOS X 10.7 and iOS version 5.0  | 
6340  |  | ** and will always return SQLITE_MISUSE. On those systems,  | 
6341  |  | ** shared cache mode should be enabled per-database connection via  | 
6342  |  | ** [sqlite3_open_v2()] with [SQLITE_OPEN_SHAREDCACHE].  | 
6343  |  | **  | 
6344  |  | ** This interface is threadsafe on processors where writing a  | 
6345  |  | ** 32-bit integer is atomic.  | 
6346  |  | **  | 
6347  |  | ** See Also:  [SQLite Shared-Cache Mode]  | 
6348  |  | */  | 
6349  |  | SQLITE_API int sqlite3_enable_shared_cache(int);  | 
6350  |  |  | 
6351  |  | /*  | 
6352  |  | ** CAPI3REF: Attempt To Free Heap Memory  | 
6353  |  | **  | 
6354  |  | ** ^The sqlite3_release_memory() interface attempts to free N bytes  | 
6355  |  | ** of heap memory by deallocating non-essential memory allocations  | 
6356  |  | ** held by the database library.   Memory used to cache database  | 
6357  |  | ** pages to improve performance is an example of non-essential memory.  | 
6358  |  | ** ^sqlite3_release_memory() returns the number of bytes actually freed,  | 
6359  |  | ** which might be more or less than the amount requested.  | 
6360  |  | ** ^The sqlite3_release_memory() routine is a no-op returning zero  | 
6361  |  | ** if SQLite is not compiled with [SQLITE_ENABLE_MEMORY_MANAGEMENT].  | 
6362  |  | **  | 
6363  |  | ** See also: [sqlite3_db_release_memory()]  | 
6364  |  | */  | 
6365  |  | SQLITE_API int sqlite3_release_memory(int);  | 
6366  |  |  | 
6367  |  | /*  | 
6368  |  | ** CAPI3REF: Free Memory Used By A Database Connection  | 
6369  |  | ** METHOD: sqlite3  | 
6370  |  | **  | 
6371  |  | ** ^The sqlite3_db_release_memory(D) interface attempts to free as much heap  | 
6372  |  | ** memory as possible from database connection D. Unlike the  | 
6373  |  | ** [sqlite3_release_memory()] interface, this interface is in effect even  | 
6374  |  | ** when the [SQLITE_ENABLE_MEMORY_MANAGEMENT] compile-time option is  | 
6375  |  | ** omitted.  | 
6376  |  | **  | 
6377  |  | ** See also: [sqlite3_release_memory()]  | 
6378  |  | */  | 
6379  |  | SQLITE_API int sqlite3_db_release_memory(sqlite3*);  | 
6380  |  |  | 
6381  |  | /*  | 
6382  |  | ** CAPI3REF: Impose A Limit On Heap Size  | 
6383  |  | **  | 
6384  |  | ** These interfaces impose limits on the amount of heap memory that will be  | 
6385  |  | ** by all database connections within a single process.  | 
6386  |  | **  | 
6387  |  | ** ^The sqlite3_soft_heap_limit64() interface sets and/or queries the  | 
6388  |  | ** soft limit on the amount of heap memory that may be allocated by SQLite.  | 
6389  |  | ** ^SQLite strives to keep heap memory utilization below the soft heap  | 
6390  |  | ** limit by reducing the number of pages held in the page cache  | 
6391  |  | ** as heap memory usages approaches the limit.  | 
6392  |  | ** ^The soft heap limit is "soft" because even though SQLite strives to stay  | 
6393  |  | ** below the limit, it will exceed the limit rather than generate  | 
6394  |  | ** an [SQLITE_NOMEM] error.  In other words, the soft heap limit  | 
6395  |  | ** is advisory only.  | 
6396  |  | **  | 
6397  |  | ** ^The sqlite3_hard_heap_limit64(N) interface sets a hard upper bound of  | 
6398  |  | ** N bytes on the amount of memory that will be allocated.  ^The  | 
6399  |  | ** sqlite3_hard_heap_limit64(N) interface is similar to  | 
6400  |  | ** sqlite3_soft_heap_limit64(N) except that memory allocations will fail  | 
6401  |  | ** when the hard heap limit is reached.  | 
6402  |  | **  | 
6403  |  | ** ^The return value from both sqlite3_soft_heap_limit64() and  | 
6404  |  | ** sqlite3_hard_heap_limit64() is the size of  | 
6405  |  | ** the heap limit prior to the call, or negative in the case of an  | 
6406  |  | ** error.  ^If the argument N is negative  | 
6407  |  | ** then no change is made to the heap limit.  Hence, the current  | 
6408  |  | ** size of heap limits can be determined by invoking  | 
6409  |  | ** sqlite3_soft_heap_limit64(-1) or sqlite3_hard_heap_limit(-1).  | 
6410  |  | **  | 
6411  |  | ** ^Setting the heap limits to zero disables the heap limiter mechanism.  | 
6412  |  | **  | 
6413  |  | ** ^The soft heap limit may not be greater than the hard heap limit.  | 
6414  |  | ** ^If the hard heap limit is enabled and if sqlite3_soft_heap_limit(N)  | 
6415  |  | ** is invoked with a value of N that is greater than the hard heap limit,  | 
6416  |  | ** the the soft heap limit is set to the value of the hard heap limit.  | 
6417  |  | ** ^The soft heap limit is automatically enabled whenever the hard heap  | 
6418  |  | ** limit is enabled. ^When sqlite3_hard_heap_limit64(N) is invoked and  | 
6419  |  | ** the soft heap limit is outside the range of 1..N, then the soft heap  | 
6420  |  | ** limit is set to N.  ^Invoking sqlite3_soft_heap_limit64(0) when the  | 
6421  |  | ** hard heap limit is enabled makes the soft heap limit equal to the  | 
6422  |  | ** hard heap limit.  | 
6423  |  | **  | 
6424  |  | ** The memory allocation limits can also be adjusted using  | 
6425  |  | ** [PRAGMA soft_heap_limit] and [PRAGMA hard_heap_limit].  | 
6426  |  | **  | 
6427  |  | ** ^(The heap limits are not enforced in the current implementation  | 
6428  |  | ** if one or more of following conditions are true:  | 
6429  |  | **  | 
6430  |  | ** <ul>  | 
6431  |  | ** <li> The limit value is set to zero.  | 
6432  |  | ** <li> Memory accounting is disabled using a combination of the  | 
6433  |  | **      [sqlite3_config]([SQLITE_CONFIG_MEMSTATUS],...) start-time option and  | 
6434  |  | **      the [SQLITE_DEFAULT_MEMSTATUS] compile-time option.  | 
6435  |  | ** <li> An alternative page cache implementation is specified using  | 
6436  |  | **      [sqlite3_config]([SQLITE_CONFIG_PCACHE2],...).  | 
6437  |  | ** <li> The page cache allocates from its own memory pool supplied  | 
6438  |  | **      by [sqlite3_config]([SQLITE_CONFIG_PAGECACHE],...) rather than  | 
6439  |  | **      from the heap.  | 
6440  |  | ** </ul>)^  | 
6441  |  | **  | 
6442  |  | ** The circumstances under which SQLite will enforce the heap limits may  | 
6443  |  | ** changes in future releases of SQLite.  | 
6444  |  | */  | 
6445  |  | SQLITE_API sqlite3_int64 sqlite3_soft_heap_limit64(sqlite3_int64 N);  | 
6446  |  | SQLITE_API sqlite3_int64 sqlite3_hard_heap_limit64(sqlite3_int64 N);  | 
6447  |  |  | 
6448  |  | /*  | 
6449  |  | ** CAPI3REF: Deprecated Soft Heap Limit Interface  | 
6450  |  | ** DEPRECATED  | 
6451  |  | **  | 
6452  |  | ** This is a deprecated version of the [sqlite3_soft_heap_limit64()]  | 
6453  |  | ** interface.  This routine is provided for historical compatibility  | 
6454  |  | ** only.  All new applications should use the  | 
6455  |  | ** [sqlite3_soft_heap_limit64()] interface rather than this one.  | 
6456  |  | */  | 
6457  |  | SQLITE_API SQLITE_DEPRECATED void sqlite3_soft_heap_limit(int N);  | 
6458  |  |  | 
6459  |  |  | 
6460  |  | /*  | 
6461  |  | ** CAPI3REF: Extract Metadata About A Column Of A Table  | 
6462  |  | ** METHOD: sqlite3  | 
6463  |  | **  | 
6464  |  | ** ^(The sqlite3_table_column_metadata(X,D,T,C,....) routine returns  | 
6465  |  | ** information about column C of table T in database D  | 
6466  |  | ** on [database connection] X.)^  ^The sqlite3_table_column_metadata()  | 
6467  |  | ** interface returns SQLITE_OK and fills in the non-NULL pointers in  | 
6468  |  | ** the final five arguments with appropriate values if the specified  | 
6469  |  | ** column exists.  ^The sqlite3_table_column_metadata() interface returns  | 
6470  |  | ** SQLITE_ERROR if the specified column does not exist.  | 
6471  |  | ** ^If the column-name parameter to sqlite3_table_column_metadata() is a  | 
6472  |  | ** NULL pointer, then this routine simply checks for the existence of the  | 
6473  |  | ** table and returns SQLITE_OK if the table exists and SQLITE_ERROR if it  | 
6474  |  | ** does not.  If the table name parameter T in a call to  | 
6475  |  | ** sqlite3_table_column_metadata(X,D,T,C,...) is NULL then the result is  | 
6476  |  | ** undefined behavior.  | 
6477  |  | **  | 
6478  |  | ** ^The column is identified by the second, third and fourth parameters to  | 
6479  |  | ** this function. ^(The second parameter is either the name of the database  | 
6480  |  | ** (i.e. "main", "temp", or an attached database) containing the specified  | 
6481  |  | ** table or NULL.)^ ^If it is NULL, then all attached databases are searched  | 
6482  |  | ** for the table using the same algorithm used by the database engine to  | 
6483  |  | ** resolve unqualified table references.  | 
6484  |  | **  | 
6485  |  | ** ^The third and fourth parameters to this function are the table and column  | 
6486  |  | ** name of the desired column, respectively.  | 
6487  |  | **  | 
6488  |  | ** ^Metadata is returned by writing to the memory locations passed as the 5th  | 
6489  |  | ** and subsequent parameters to this function. ^Any of these arguments may be  | 
6490  |  | ** NULL, in which case the corresponding element of metadata is omitted.  | 
6491  |  | **  | 
6492  |  | ** ^(<blockquote>  | 
6493  |  | ** <table border="1">  | 
6494  |  | ** <tr><th> Parameter <th> Output<br>Type <th>  Description  | 
6495  |  | **  | 
6496  |  | ** <tr><td> 5th <td> const char* <td> Data type  | 
6497  |  | ** <tr><td> 6th <td> const char* <td> Name of default collation sequence  | 
6498  |  | ** <tr><td> 7th <td> int         <td> True if column has a NOT NULL constraint  | 
6499  |  | ** <tr><td> 8th <td> int         <td> True if column is part of the PRIMARY KEY  | 
6500  |  | ** <tr><td> 9th <td> int         <td> True if column is [AUTOINCREMENT]  | 
6501  |  | ** </table>  | 
6502  |  | ** </blockquote>)^  | 
6503  |  | **  | 
6504  |  | ** ^The memory pointed to by the character pointers returned for the  | 
6505  |  | ** declaration type and collation sequence is valid until the next  | 
6506  |  | ** call to any SQLite API function.  | 
6507  |  | **  | 
6508  |  | ** ^If the specified table is actually a view, an [error code] is returned.  | 
6509  |  | **  | 
6510  |  | ** ^If the specified column is "rowid", "oid" or "_rowid_" and the table  | 
6511  |  | ** is not a [WITHOUT ROWID] table and an  | 
6512  |  | ** [INTEGER PRIMARY KEY] column has been explicitly declared, then the output  | 
6513  |  | ** parameters are set for the explicitly declared column. ^(If there is no  | 
6514  |  | ** [INTEGER PRIMARY KEY] column, then the outputs  | 
6515  |  | ** for the [rowid] are set as follows:  | 
6516  |  | **  | 
6517  |  | ** <pre>  | 
6518  |  | **     data type: "INTEGER"  | 
6519  |  | **     collation sequence: "BINARY"  | 
6520  |  | **     not null: 0  | 
6521  |  | **     primary key: 1  | 
6522  |  | **     auto increment: 0  | 
6523  |  | ** </pre>)^  | 
6524  |  | **  | 
6525  |  | ** ^This function causes all database schemas to be read from disk and  | 
6526  |  | ** parsed, if that has not already been done, and returns an error if  | 
6527  |  | ** any errors are encountered while loading the schema.  | 
6528  |  | */  | 
6529  |  | SQLITE_API int sqlite3_table_column_metadata(  | 
6530  |  |   sqlite3 *db,                /* Connection handle */  | 
6531  |  |   const char *zDbName,        /* Database name or NULL */  | 
6532  |  |   const char *zTableName,     /* Table name */  | 
6533  |  |   const char *zColumnName,    /* Column name */  | 
6534  |  |   char const **pzDataType,    /* OUTPUT: Declared data type */  | 
6535  |  |   char const **pzCollSeq,     /* OUTPUT: Collation sequence name */  | 
6536  |  |   int *pNotNull,              /* OUTPUT: True if NOT NULL constraint exists */  | 
6537  |  |   int *pPrimaryKey,           /* OUTPUT: True if column part of PK */  | 
6538  |  |   int *pAutoinc               /* OUTPUT: True if column is auto-increment */  | 
6539  |  | );  | 
6540  |  |  | 
6541  |  | /*  | 
6542  |  | ** CAPI3REF: Load An Extension  | 
6543  |  | ** METHOD: sqlite3  | 
6544  |  | **  | 
6545  |  | ** ^This interface loads an SQLite extension library from the named file.  | 
6546  |  | **  | 
6547  |  | ** ^The sqlite3_load_extension() interface attempts to load an  | 
6548  |  | ** [SQLite extension] library contained in the file zFile.  If  | 
6549  |  | ** the file cannot be loaded directly, attempts are made to load  | 
6550  |  | ** with various operating-system specific extensions added.  | 
6551  |  | ** So for example, if "samplelib" cannot be loaded, then names like  | 
6552  |  | ** "samplelib.so" or "samplelib.dylib" or "samplelib.dll" might  | 
6553  |  | ** be tried also.  | 
6554  |  | **  | 
6555  |  | ** ^The entry point is zProc.  | 
6556  |  | ** ^(zProc may be 0, in which case SQLite will try to come up with an  | 
6557  |  | ** entry point name on its own.  It first tries "sqlite3_extension_init".  | 
6558  |  | ** If that does not work, it constructs a name "sqlite3_X_init" where the  | 
6559  |  | ** X is consists of the lower-case equivalent of all ASCII alphabetic  | 
6560  |  | ** characters in the filename from the last "/" to the first following  | 
6561  |  | ** "." and omitting any initial "lib".)^  | 
6562  |  | ** ^The sqlite3_load_extension() interface returns  | 
6563  |  | ** [SQLITE_OK] on success and [SQLITE_ERROR] if something goes wrong.  | 
6564  |  | ** ^If an error occurs and pzErrMsg is not 0, then the  | 
6565  |  | ** [sqlite3_load_extension()] interface shall attempt to  | 
6566  |  | ** fill *pzErrMsg with error message text stored in memory  | 
6567  |  | ** obtained from [sqlite3_malloc()]. The calling function  | 
6568  |  | ** should free this memory by calling [sqlite3_free()].  | 
6569  |  | **  | 
6570  |  | ** ^Extension loading must be enabled using  | 
6571  |  | ** [sqlite3_enable_load_extension()] or  | 
6572  |  | ** [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION],1,NULL)  | 
6573  |  | ** prior to calling this API,  | 
6574  |  | ** otherwise an error will be returned.  | 
6575  |  | **  | 
6576  |  | ** <b>Security warning:</b> It is recommended that the  | 
6577  |  | ** [SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION] method be used to enable only this  | 
6578  |  | ** interface.  The use of the [sqlite3_enable_load_extension()] interface  | 
6579  |  | ** should be avoided.  This will keep the SQL function [load_extension()]  | 
6580  |  | ** disabled and prevent SQL injections from giving attackers  | 
6581  |  | ** access to extension loading capabilities.  | 
6582  |  | **  | 
6583  |  | ** See also the [load_extension() SQL function].  | 
6584  |  | */  | 
6585  |  | SQLITE_API int sqlite3_load_extension(  | 
6586  |  |   sqlite3 *db,          /* Load the extension into this database connection */  | 
6587  |  |   const char *zFile,    /* Name of the shared library containing extension */  | 
6588  |  |   const char *zProc,    /* Entry point.  Derived from zFile if 0 */  | 
6589  |  |   char **pzErrMsg       /* Put error message here if not 0 */  | 
6590  |  | );  | 
6591  |  |  | 
6592  |  | /*  | 
6593  |  | ** CAPI3REF: Enable Or Disable Extension Loading  | 
6594  |  | ** METHOD: sqlite3  | 
6595  |  | **  | 
6596  |  | ** ^So as not to open security holes in older applications that are  | 
6597  |  | ** unprepared to deal with [extension loading], and as a means of disabling  | 
6598  |  | ** [extension loading] while evaluating user-entered SQL, the following API  | 
6599  |  | ** is provided to turn the [sqlite3_load_extension()] mechanism on and off.  | 
6600  |  | **  | 
6601  |  | ** ^Extension loading is off by default.  | 
6602  |  | ** ^Call the sqlite3_enable_load_extension() routine with onoff==1  | 
6603  |  | ** to turn extension loading on and call it with onoff==0 to turn  | 
6604  |  | ** it back off again.  | 
6605  |  | **  | 
6606  |  | ** ^This interface enables or disables both the C-API  | 
6607  |  | ** [sqlite3_load_extension()] and the SQL function [load_extension()].  | 
6608  |  | ** ^(Use [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION],..)  | 
6609  |  | ** to enable or disable only the C-API.)^  | 
6610  |  | **  | 
6611  |  | ** <b>Security warning:</b> It is recommended that extension loading  | 
6612  |  | ** be enabled using the [SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION] method  | 
6613  |  | ** rather than this interface, so the [load_extension()] SQL function  | 
6614  |  | ** remains disabled. This will prevent SQL injections from giving attackers  | 
6615  |  | ** access to extension loading capabilities.  | 
6616  |  | */  | 
6617  |  | SQLITE_API int sqlite3_enable_load_extension(sqlite3 *db, int onoff);  | 
6618  |  |  | 
6619  |  | /*  | 
6620  |  | ** CAPI3REF: Automatically Load Statically Linked Extensions  | 
6621  |  | **  | 
6622  |  | ** ^This interface causes the xEntryPoint() function to be invoked for  | 
6623  |  | ** each new [database connection] that is created.  The idea here is that  | 
6624  |  | ** xEntryPoint() is the entry point for a statically linked [SQLite extension]  | 
6625  |  | ** that is to be automatically loaded into all new database connections.  | 
6626  |  | **  | 
6627  |  | ** ^(Even though the function prototype shows that xEntryPoint() takes  | 
6628  |  | ** no arguments and returns void, SQLite invokes xEntryPoint() with three  | 
6629  |  | ** arguments and expects an integer result as if the signature of the  | 
6630  |  | ** entry point where as follows:  | 
6631  |  | **  | 
6632  |  | ** <blockquote><pre>  | 
6633  |  | **    int xEntryPoint(  | 
6634  |  | **      sqlite3 *db,  | 
6635  |  | **      const char **pzErrMsg,  | 
6636  |  | **      const struct sqlite3_api_routines *pThunk  | 
6637  |  | **    );  | 
6638  |  | ** </pre></blockquote>)^  | 
6639  |  | **  | 
6640  |  | ** If the xEntryPoint routine encounters an error, it should make *pzErrMsg  | 
6641  |  | ** point to an appropriate error message (obtained from [sqlite3_mprintf()])  | 
6642  |  | ** and return an appropriate [error code].  ^SQLite ensures that *pzErrMsg  | 
6643  |  | ** is NULL before calling the xEntryPoint().  ^SQLite will invoke  | 
6644  |  | ** [sqlite3_free()] on *pzErrMsg after xEntryPoint() returns.  ^If any  | 
6645  |  | ** xEntryPoint() returns an error, the [sqlite3_open()], [sqlite3_open16()],  | 
6646  |  | ** or [sqlite3_open_v2()] call that provoked the xEntryPoint() will fail.  | 
6647  |  | **  | 
6648  |  | ** ^Calling sqlite3_auto_extension(X) with an entry point X that is already  | 
6649  |  | ** on the list of automatic extensions is a harmless no-op. ^No entry point  | 
6650  |  | ** will be called more than once for each database connection that is opened.  | 
6651  |  | **  | 
6652  |  | ** See also: [sqlite3_reset_auto_extension()]  | 
6653  |  | ** and [sqlite3_cancel_auto_extension()]  | 
6654  |  | */  | 
6655  |  | SQLITE_API int sqlite3_auto_extension(void(*xEntryPoint)(void));  | 
6656  |  |  | 
6657  |  | /*  | 
6658  |  | ** CAPI3REF: Cancel Automatic Extension Loading  | 
6659  |  | **  | 
6660  |  | ** ^The [sqlite3_cancel_auto_extension(X)] interface unregisters the  | 
6661  |  | ** initialization routine X that was registered using a prior call to  | 
6662  |  | ** [sqlite3_auto_extension(X)].  ^The [sqlite3_cancel_auto_extension(X)]  | 
6663  |  | ** routine returns 1 if initialization routine X was successfully  | 
6664  |  | ** unregistered and it returns 0 if X was not on the list of initialization  | 
6665  |  | ** routines.  | 
6666  |  | */  | 
6667  |  | SQLITE_API int sqlite3_cancel_auto_extension(void(*xEntryPoint)(void));  | 
6668  |  |  | 
6669  |  | /*  | 
6670  |  | ** CAPI3REF: Reset Automatic Extension Loading  | 
6671  |  | **  | 
6672  |  | ** ^This interface disables all automatic extensions previously  | 
6673  |  | ** registered using [sqlite3_auto_extension()].  | 
6674  |  | */  | 
6675  |  | SQLITE_API void sqlite3_reset_auto_extension(void);  | 
6676  |  |  | 
6677  |  | /*  | 
6678  |  | ** The interface to the virtual-table mechanism is currently considered  | 
6679  |  | ** to be experimental.  The interface might change in incompatible ways.  | 
6680  |  | ** If this is a problem for you, do not use the interface at this time.  | 
6681  |  | **  | 
6682  |  | ** When the virtual-table mechanism stabilizes, we will declare the  | 
6683  |  | ** interface fixed, support it indefinitely, and remove this comment.  | 
6684  |  | */  | 
6685  |  |  | 
6686  |  | /*  | 
6687  |  | ** Structures used by the virtual table interface  | 
6688  |  | */  | 
6689  |  | typedef struct sqlite3_vtab sqlite3_vtab;  | 
6690  |  | typedef struct sqlite3_index_info sqlite3_index_info;  | 
6691  |  | typedef struct sqlite3_vtab_cursor sqlite3_vtab_cursor;  | 
6692  |  | typedef struct sqlite3_module sqlite3_module;  | 
6693  |  |  | 
6694  |  | /*  | 
6695  |  | ** CAPI3REF: Virtual Table Object  | 
6696  |  | ** KEYWORDS: sqlite3_module {virtual table module} | 
6697  |  | **  | 
6698  |  | ** This structure, sometimes called a "virtual table module",  | 
6699  |  | ** defines the implementation of a [virtual table].  | 
6700  |  | ** This structure consists mostly of methods for the module.  | 
6701  |  | **  | 
6702  |  | ** ^A virtual table module is created by filling in a persistent  | 
6703  |  | ** instance of this structure and passing a pointer to that instance  | 
6704  |  | ** to [sqlite3_create_module()] or [sqlite3_create_module_v2()].  | 
6705  |  | ** ^The registration remains valid until it is replaced by a different  | 
6706  |  | ** module or until the [database connection] closes.  The content  | 
6707  |  | ** of this structure must not change while it is registered with  | 
6708  |  | ** any database connection.  | 
6709  |  | */  | 
6710  |  | struct sqlite3_module { | 
6711  |  |   int iVersion;  | 
6712  |  |   int (*xCreate)(sqlite3*, void *pAux,  | 
6713  |  |                int argc, const char *const*argv,  | 
6714  |  |                sqlite3_vtab **ppVTab, char**);  | 
6715  |  |   int (*xConnect)(sqlite3*, void *pAux,  | 
6716  |  |                int argc, const char *const*argv,  | 
6717  |  |                sqlite3_vtab **ppVTab, char**);  | 
6718  |  |   int (*xBestIndex)(sqlite3_vtab *pVTab, sqlite3_index_info*);  | 
6719  |  |   int (*xDisconnect)(sqlite3_vtab *pVTab);  | 
6720  |  |   int (*xDestroy)(sqlite3_vtab *pVTab);  | 
6721  |  |   int (*xOpen)(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor);  | 
6722  |  |   int (*xClose)(sqlite3_vtab_cursor*);  | 
6723  |  |   int (*xFilter)(sqlite3_vtab_cursor*, int idxNum, const char *idxStr,  | 
6724  |  |                 int argc, sqlite3_value **argv);  | 
6725  |  |   int (*xNext)(sqlite3_vtab_cursor*);  | 
6726  |  |   int (*xEof)(sqlite3_vtab_cursor*);  | 
6727  |  |   int (*xColumn)(sqlite3_vtab_cursor*, sqlite3_context*, int);  | 
6728  |  |   int (*xRowid)(sqlite3_vtab_cursor*, sqlite3_int64 *pRowid);  | 
6729  |  |   int (*xUpdate)(sqlite3_vtab *, int, sqlite3_value **, sqlite3_int64 *);  | 
6730  |  |   int (*xBegin)(sqlite3_vtab *pVTab);  | 
6731  |  |   int (*xSync)(sqlite3_vtab *pVTab);  | 
6732  |  |   int (*xCommit)(sqlite3_vtab *pVTab);  | 
6733  |  |   int (*xRollback)(sqlite3_vtab *pVTab);  | 
6734  |  |   int (*xFindFunction)(sqlite3_vtab *pVtab, int nArg, const char *zName,  | 
6735  |  |                        void (**pxFunc)(sqlite3_context*,int,sqlite3_value**),  | 
6736  |  |                        void **ppArg);  | 
6737  |  |   int (*xRename)(sqlite3_vtab *pVtab, const char *zNew);  | 
6738  |  |   /* The methods above are in version 1 of the sqlite_module object. Those  | 
6739  |  |   ** below are for version 2 and greater. */  | 
6740  |  |   int (*xSavepoint)(sqlite3_vtab *pVTab, int);  | 
6741  |  |   int (*xRelease)(sqlite3_vtab *pVTab, int);  | 
6742  |  |   int (*xRollbackTo)(sqlite3_vtab *pVTab, int);  | 
6743  |  |   /* The methods above are in versions 1 and 2 of the sqlite_module object.  | 
6744  |  |   ** Those below are for version 3 and greater. */  | 
6745  |  |   int (*xShadowName)(const char*);  | 
6746  |  | };  | 
6747  |  |  | 
6748  |  | /*  | 
6749  |  | ** CAPI3REF: Virtual Table Indexing Information  | 
6750  |  | ** KEYWORDS: sqlite3_index_info  | 
6751  |  | **  | 
6752  |  | ** The sqlite3_index_info structure and its substructures is used as part  | 
6753  |  | ** of the [virtual table] interface to  | 
6754  |  | ** pass information into and receive the reply from the [xBestIndex]  | 
6755  |  | ** method of a [virtual table module].  The fields under **Inputs** are the  | 
6756  |  | ** inputs to xBestIndex and are read-only.  xBestIndex inserts its  | 
6757  |  | ** results into the **Outputs** fields.  | 
6758  |  | **  | 
6759  |  | ** ^(The aConstraint[] array records WHERE clause constraints of the form:  | 
6760  |  | **  | 
6761  |  | ** <blockquote>column OP expr</blockquote>  | 
6762  |  | **  | 
6763  |  | ** where OP is =, <, <=, >, or >=.)^  ^(The particular operator is  | 
6764  |  | ** stored in aConstraint[].op using one of the  | 
6765  |  | ** [SQLITE_INDEX_CONSTRAINT_EQ | SQLITE_INDEX_CONSTRAINT_ values].)^  | 
6766  |  | ** ^(The index of the column is stored in  | 
6767  |  | ** aConstraint[].iColumn.)^  ^(aConstraint[].usable is TRUE if the  | 
6768  |  | ** expr on the right-hand side can be evaluated (and thus the constraint  | 
6769  |  | ** is usable) and false if it cannot.)^  | 
6770  |  | **  | 
6771  |  | ** ^The optimizer automatically inverts terms of the form "expr OP column"  | 
6772  |  | ** and makes other simplifications to the WHERE clause in an attempt to  | 
6773  |  | ** get as many WHERE clause terms into the form shown above as possible.  | 
6774  |  | ** ^The aConstraint[] array only reports WHERE clause terms that are  | 
6775  |  | ** relevant to the particular virtual table being queried.  | 
6776  |  | **  | 
6777  |  | ** ^Information about the ORDER BY clause is stored in aOrderBy[].  | 
6778  |  | ** ^Each term of aOrderBy records a column of the ORDER BY clause.  | 
6779  |  | **  | 
6780  |  | ** The colUsed field indicates which columns of the virtual table may be  | 
6781  |  | ** required by the current scan. Virtual table columns are numbered from  | 
6782  |  | ** zero in the order in which they appear within the CREATE TABLE statement  | 
6783  |  | ** passed to sqlite3_declare_vtab(). For the first 63 columns (columns 0-62),  | 
6784  |  | ** the corresponding bit is set within the colUsed mask if the column may be  | 
6785  |  | ** required by SQLite. If the table has at least 64 columns and any column  | 
6786  |  | ** to the right of the first 63 is required, then bit 63 of colUsed is also  | 
6787  |  | ** set. In other words, column iCol may be required if the expression  | 
6788  |  | ** (colUsed & ((sqlite3_uint64)1 << (iCol>=63 ? 63 : iCol))) evaluates to  | 
6789  |  | ** non-zero.  | 
6790  |  | **  | 
6791  |  | ** The [xBestIndex] method must fill aConstraintUsage[] with information  | 
6792  |  | ** about what parameters to pass to xFilter.  ^If argvIndex>0 then  | 
6793  |  | ** the right-hand side of the corresponding aConstraint[] is evaluated  | 
6794  |  | ** and becomes the argvIndex-th entry in argv.  ^(If aConstraintUsage[].omit  | 
6795  |  | ** is true, then the constraint is assumed to be fully handled by the  | 
6796  |  | ** virtual table and might not be checked again by the byte code.)^ ^(The  | 
6797  |  | ** aConstraintUsage[].omit flag is an optimization hint. When the omit flag  | 
6798  |  | ** is left in its default setting of false, the constraint will always be  | 
6799  |  | ** checked separately in byte code.  If the omit flag is change to true, then  | 
6800  |  | ** the constraint may or may not be checked in byte code.  In other words,  | 
6801  |  | ** when the omit flag is true there is no guarantee that the constraint will  | 
6802  |  | ** not be checked again using byte code.)^  | 
6803  |  | **  | 
6804  |  | ** ^The idxNum and idxPtr values are recorded and passed into the  | 
6805  |  | ** [xFilter] method.  | 
6806  |  | ** ^[sqlite3_free()] is used to free idxPtr if and only if  | 
6807  |  | ** needToFreeIdxPtr is true.  | 
6808  |  | **  | 
6809  |  | ** ^The orderByConsumed means that output from [xFilter]/[xNext] will occur in  | 
6810  |  | ** the correct order to satisfy the ORDER BY clause so that no separate  | 
6811  |  | ** sorting step is required.  | 
6812  |  | **  | 
6813  |  | ** ^The estimatedCost value is an estimate of the cost of a particular  | 
6814  |  | ** strategy. A cost of N indicates that the cost of the strategy is similar  | 
6815  |  | ** to a linear scan of an SQLite table with N rows. A cost of log(N)  | 
6816  |  | ** indicates that the expense of the operation is similar to that of a  | 
6817  |  | ** binary search on a unique indexed field of an SQLite table with N rows.  | 
6818  |  | **  | 
6819  |  | ** ^The estimatedRows value is an estimate of the number of rows that  | 
6820  |  | ** will be returned by the strategy.  | 
6821  |  | **  | 
6822  |  | ** The xBestIndex method may optionally populate the idxFlags field with a  | 
6823  |  | ** mask of SQLITE_INDEX_SCAN_* flags. Currently there is only one such flag -  | 
6824  |  | ** SQLITE_INDEX_SCAN_UNIQUE. If the xBestIndex method sets this flag, SQLite  | 
6825  |  | ** assumes that the strategy may visit at most one row.  | 
6826  |  | **  | 
6827  |  | ** Additionally, if xBestIndex sets the SQLITE_INDEX_SCAN_UNIQUE flag, then  | 
6828  |  | ** SQLite also assumes that if a call to the xUpdate() method is made as  | 
6829  |  | ** part of the same statement to delete or update a virtual table row and the  | 
6830  |  | ** implementation returns SQLITE_CONSTRAINT, then there is no need to rollback  | 
6831  |  | ** any database changes. In other words, if the xUpdate() returns  | 
6832  |  | ** SQLITE_CONSTRAINT, the database contents must be exactly as they were  | 
6833  |  | ** before xUpdate was called. By contrast, if SQLITE_INDEX_SCAN_UNIQUE is not  | 
6834  |  | ** set and xUpdate returns SQLITE_CONSTRAINT, any database changes made by  | 
6835  |  | ** the xUpdate method are automatically rolled back by SQLite.  | 
6836  |  | **  | 
6837  |  | ** IMPORTANT: The estimatedRows field was added to the sqlite3_index_info  | 
6838  |  | ** structure for SQLite [version 3.8.2] ([dateof:3.8.2]).  | 
6839  |  | ** If a virtual table extension is  | 
6840  |  | ** used with an SQLite version earlier than 3.8.2, the results of attempting  | 
6841  |  | ** to read or write the estimatedRows field are undefined (but are likely  | 
6842  |  | ** to include crashing the application). The estimatedRows field should  | 
6843  |  | ** therefore only be used if [sqlite3_libversion_number()] returns a  | 
6844  |  | ** value greater than or equal to 3008002. Similarly, the idxFlags field  | 
6845  |  | ** was added for [version 3.9.0] ([dateof:3.9.0]).  | 
6846  |  | ** It may therefore only be used if  | 
6847  |  | ** sqlite3_libversion_number() returns a value greater than or equal to  | 
6848  |  | ** 3009000.  | 
6849  |  | */  | 
6850  |  | struct sqlite3_index_info { | 
6851  |  |   /* Inputs */  | 
6852  |  |   int nConstraint;           /* Number of entries in aConstraint */  | 
6853  |  |   struct sqlite3_index_constraint { | 
6854  |  |      int iColumn;              /* Column constrained.  -1 for ROWID */  | 
6855  |  |      unsigned char op;         /* Constraint operator */  | 
6856  |  |      unsigned char usable;     /* True if this constraint is usable */  | 
6857  |  |      int iTermOffset;          /* Used internally - xBestIndex should ignore */  | 
6858  |  |   } *aConstraint;            /* Table of WHERE clause constraints */  | 
6859  |  |   int nOrderBy;              /* Number of terms in the ORDER BY clause */  | 
6860  |  |   struct sqlite3_index_orderby { | 
6861  |  |      int iColumn;              /* Column number */  | 
6862  |  |      unsigned char desc;       /* True for DESC.  False for ASC. */  | 
6863  |  |   } *aOrderBy;               /* The ORDER BY clause */  | 
6864  |  |   /* Outputs */  | 
6865  |  |   struct sqlite3_index_constraint_usage { | 
6866  |  |     int argvIndex;           /* if >0, constraint is part of argv to xFilter */  | 
6867  |  |     unsigned char omit;      /* Do not code a test for this constraint */  | 
6868  |  |   } *aConstraintUsage;  | 
6869  |  |   int idxNum;                /* Number used to identify the index */  | 
6870  |  |   char *idxStr;              /* String, possibly obtained from sqlite3_malloc */  | 
6871  |  |   int needToFreeIdxStr;      /* Free idxStr using sqlite3_free() if true */  | 
6872  |  |   int orderByConsumed;       /* True if output is already ordered */  | 
6873  |  |   double estimatedCost;           /* Estimated cost of using this index */  | 
6874  |  |   /* Fields below are only available in SQLite 3.8.2 and later */  | 
6875  |  |   sqlite3_int64 estimatedRows;    /* Estimated number of rows returned */  | 
6876  |  |   /* Fields below are only available in SQLite 3.9.0 and later */  | 
6877  |  |   int idxFlags;              /* Mask of SQLITE_INDEX_SCAN_* flags */  | 
6878  |  |   /* Fields below are only available in SQLite 3.10.0 and later */  | 
6879  |  |   sqlite3_uint64 colUsed;    /* Input: Mask of columns used by statement */  | 
6880  |  | };  | 
6881  |  |  | 
6882  |  | /*  | 
6883  |  | ** CAPI3REF: Virtual Table Scan Flags  | 
6884  |  | **  | 
6885  |  | ** Virtual table implementations are allowed to set the  | 
6886  |  | ** [sqlite3_index_info].idxFlags field to some combination of  | 
6887  |  | ** these bits.  | 
6888  |  | */  | 
6889  |  | #define SQLITE_INDEX_SCAN_UNIQUE      1     /* Scan visits at most 1 row */  | 
6890  |  |  | 
6891  |  | /*  | 
6892  |  | ** CAPI3REF: Virtual Table Constraint Operator Codes  | 
6893  |  | **  | 
6894  |  | ** These macros define the allowed values for the  | 
6895  |  | ** [sqlite3_index_info].aConstraint[].op field.  Each value represents  | 
6896  |  | ** an operator that is part of a constraint term in the wHERE clause of  | 
6897  |  | ** a query that uses a [virtual table].  | 
6898  |  | */  | 
6899  |  | #define SQLITE_INDEX_CONSTRAINT_EQ         2  | 
6900  |  | #define SQLITE_INDEX_CONSTRAINT_GT         4  | 
6901  |  | #define SQLITE_INDEX_CONSTRAINT_LE         8  | 
6902  |  | #define SQLITE_INDEX_CONSTRAINT_LT        16  | 
6903  |  | #define SQLITE_INDEX_CONSTRAINT_GE        32  | 
6904  |  | #define SQLITE_INDEX_CONSTRAINT_MATCH     64  | 
6905  |  | #define SQLITE_INDEX_CONSTRAINT_LIKE      65  | 
6906  |  | #define SQLITE_INDEX_CONSTRAINT_GLOB      66  | 
6907  |  | #define SQLITE_INDEX_CONSTRAINT_REGEXP    67  | 
6908  |  | #define SQLITE_INDEX_CONSTRAINT_NE        68  | 
6909  |  | #define SQLITE_INDEX_CONSTRAINT_ISNOT     69  | 
6910  |  | #define SQLITE_INDEX_CONSTRAINT_ISNOTNULL 70  | 
6911  |  | #define SQLITE_INDEX_CONSTRAINT_ISNULL    71  | 
6912  |  | #define SQLITE_INDEX_CONSTRAINT_IS        72  | 
6913  |  | #define SQLITE_INDEX_CONSTRAINT_FUNCTION 150  | 
6914  |  |  | 
6915  |  | /*  | 
6916  |  | ** CAPI3REF: Register A Virtual Table Implementation  | 
6917  |  | ** METHOD: sqlite3  | 
6918  |  | **  | 
6919  |  | ** ^These routines are used to register a new [virtual table module] name.  | 
6920  |  | ** ^Module names must be registered before  | 
6921  |  | ** creating a new [virtual table] using the module and before using a  | 
6922  |  | ** preexisting [virtual table] for the module.  | 
6923  |  | **  | 
6924  |  | ** ^The module name is registered on the [database connection] specified  | 
6925  |  | ** by the first parameter.  ^The name of the module is given by the  | 
6926  |  | ** second parameter.  ^The third parameter is a pointer to  | 
6927  |  | ** the implementation of the [virtual table module].   ^The fourth  | 
6928  |  | ** parameter is an arbitrary client data pointer that is passed through  | 
6929  |  | ** into the [xCreate] and [xConnect] methods of the virtual table module  | 
6930  |  | ** when a new virtual table is be being created or reinitialized.  | 
6931  |  | **  | 
6932  |  | ** ^The sqlite3_create_module_v2() interface has a fifth parameter which  | 
6933  |  | ** is a pointer to a destructor for the pClientData.  ^SQLite will  | 
6934  |  | ** invoke the destructor function (if it is not NULL) when SQLite  | 
6935  |  | ** no longer needs the pClientData pointer.  ^The destructor will also  | 
6936  |  | ** be invoked if the call to sqlite3_create_module_v2() fails.  | 
6937  |  | ** ^The sqlite3_create_module()  | 
6938  |  | ** interface is equivalent to sqlite3_create_module_v2() with a NULL  | 
6939  |  | ** destructor.  | 
6940  |  | **  | 
6941  |  | ** ^If the third parameter (the pointer to the sqlite3_module object) is  | 
6942  |  | ** NULL then no new module is create and any existing modules with the  | 
6943  |  | ** same name are dropped.  | 
6944  |  | **  | 
6945  |  | ** See also: [sqlite3_drop_modules()]  | 
6946  |  | */  | 
6947  |  | SQLITE_API int sqlite3_create_module(  | 
6948  |  |   sqlite3 *db,               /* SQLite connection to register module with */  | 
6949  |  |   const char *zName,         /* Name of the module */  | 
6950  |  |   const sqlite3_module *p,   /* Methods for the module */  | 
6951  |  |   void *pClientData          /* Client data for xCreate/xConnect */  | 
6952  |  | );  | 
6953  |  | SQLITE_API int sqlite3_create_module_v2(  | 
6954  |  |   sqlite3 *db,               /* SQLite connection to register module with */  | 
6955  |  |   const char *zName,         /* Name of the module */  | 
6956  |  |   const sqlite3_module *p,   /* Methods for the module */  | 
6957  |  |   void *pClientData,         /* Client data for xCreate/xConnect */  | 
6958  |  |   void(*xDestroy)(void*)     /* Module destructor function */  | 
6959  |  | );  | 
6960  |  |  | 
6961  |  | /*  | 
6962  |  | ** CAPI3REF: Remove Unnecessary Virtual Table Implementations  | 
6963  |  | ** METHOD: sqlite3  | 
6964  |  | **  | 
6965  |  | ** ^The sqlite3_drop_modules(D,L) interface removes all virtual  | 
6966  |  | ** table modules from database connection D except those named on list L.  | 
6967  |  | ** The L parameter must be either NULL or a pointer to an array of pointers  | 
6968  |  | ** to strings where the array is terminated by a single NULL pointer.  | 
6969  |  | ** ^If the L parameter is NULL, then all virtual table modules are removed.  | 
6970  |  | **  | 
6971  |  | ** See also: [sqlite3_create_module()]  | 
6972  |  | */  | 
6973  |  | SQLITE_API int sqlite3_drop_modules(  | 
6974  |  |   sqlite3 *db,                /* Remove modules from this connection */  | 
6975  |  |   const char **azKeep         /* Except, do not remove the ones named here */  | 
6976  |  | );  | 
6977  |  |  | 
6978  |  | /*  | 
6979  |  | ** CAPI3REF: Virtual Table Instance Object  | 
6980  |  | ** KEYWORDS: sqlite3_vtab  | 
6981  |  | **  | 
6982  |  | ** Every [virtual table module] implementation uses a subclass  | 
6983  |  | ** of this object to describe a particular instance  | 
6984  |  | ** of the [virtual table].  Each subclass will  | 
6985  |  | ** be tailored to the specific needs of the module implementation.  | 
6986  |  | ** The purpose of this superclass is to define certain fields that are  | 
6987  |  | ** common to all module implementations.  | 
6988  |  | **  | 
6989  |  | ** ^Virtual tables methods can set an error message by assigning a  | 
6990  |  | ** string obtained from [sqlite3_mprintf()] to zErrMsg.  The method should  | 
6991  |  | ** take care that any prior string is freed by a call to [sqlite3_free()]  | 
6992  |  | ** prior to assigning a new string to zErrMsg.  ^After the error message  | 
6993  |  | ** is delivered up to the client application, the string will be automatically  | 
6994  |  | ** freed by sqlite3_free() and the zErrMsg field will be zeroed.  | 
6995  |  | */  | 
6996  |  | struct sqlite3_vtab { | 
6997  |  |   const sqlite3_module *pModule;  /* The module for this virtual table */  | 
6998  |  |   int nRef;                       /* Number of open cursors */  | 
6999  |  |   char *zErrMsg;                  /* Error message from sqlite3_mprintf() */  | 
7000  |  |   /* Virtual table implementations will typically add additional fields */  | 
7001  |  | };  | 
7002  |  |  | 
7003  |  | /*  | 
7004  |  | ** CAPI3REF: Virtual Table Cursor Object  | 
7005  |  | ** KEYWORDS: sqlite3_vtab_cursor {virtual table cursor} | 
7006  |  | **  | 
7007  |  | ** Every [virtual table module] implementation uses a subclass of the  | 
7008  |  | ** following structure to describe cursors that point into the  | 
7009  |  | ** [virtual table] and are used  | 
7010  |  | ** to loop through the virtual table.  Cursors are created using the  | 
7011  |  | ** [sqlite3_module.xOpen | xOpen] method of the module and are destroyed  | 
7012  |  | ** by the [sqlite3_module.xClose | xClose] method.  Cursors are used  | 
7013  |  | ** by the [xFilter], [xNext], [xEof], [xColumn], and [xRowid] methods  | 
7014  |  | ** of the module.  Each module implementation will define  | 
7015  |  | ** the content of a cursor structure to suit its own needs.  | 
7016  |  | **  | 
7017  |  | ** This superclass exists in order to define fields of the cursor that  | 
7018  |  | ** are common to all implementations.  | 
7019  |  | */  | 
7020  |  | struct sqlite3_vtab_cursor { | 
7021  |  |   sqlite3_vtab *pVtab;      /* Virtual table of this cursor */  | 
7022  |  |   /* Virtual table implementations will typically add additional fields */  | 
7023  |  | };  | 
7024  |  |  | 
7025  |  | /*  | 
7026  |  | ** CAPI3REF: Declare The Schema Of A Virtual Table  | 
7027  |  | **  | 
7028  |  | ** ^The [xCreate] and [xConnect] methods of a  | 
7029  |  | ** [virtual table module] call this interface  | 
7030  |  | ** to declare the format (the names and datatypes of the columns) of  | 
7031  |  | ** the virtual tables they implement.  | 
7032  |  | */  | 
7033  |  | SQLITE_API int sqlite3_declare_vtab(sqlite3*, const char *zSQL);  | 
7034  |  |  | 
7035  |  | /*  | 
7036  |  | ** CAPI3REF: Overload A Function For A Virtual Table  | 
7037  |  | ** METHOD: sqlite3  | 
7038  |  | **  | 
7039  |  | ** ^(Virtual tables can provide alternative implementations of functions  | 
7040  |  | ** using the [xFindFunction] method of the [virtual table module].  | 
7041  |  | ** But global versions of those functions  | 
7042  |  | ** must exist in order to be overloaded.)^  | 
7043  |  | **  | 
7044  |  | ** ^(This API makes sure a global version of a function with a particular  | 
7045  |  | ** name and number of parameters exists.  If no such function exists  | 
7046  |  | ** before this API is called, a new function is created.)^  ^The implementation  | 
7047  |  | ** of the new function always causes an exception to be thrown.  So  | 
7048  |  | ** the new function is not good for anything by itself.  Its only  | 
7049  |  | ** purpose is to be a placeholder function that can be overloaded  | 
7050  |  | ** by a [virtual table].  | 
7051  |  | */  | 
7052  |  | SQLITE_API int sqlite3_overload_function(sqlite3*, const char *zFuncName, int nArg);  | 
7053  |  |  | 
7054  |  | /*  | 
7055  |  | ** The interface to the virtual-table mechanism defined above (back up  | 
7056  |  | ** to a comment remarkably similar to this one) is currently considered  | 
7057  |  | ** to be experimental.  The interface might change in incompatible ways.  | 
7058  |  | ** If this is a problem for you, do not use the interface at this time.  | 
7059  |  | **  | 
7060  |  | ** When the virtual-table mechanism stabilizes, we will declare the  | 
7061  |  | ** interface fixed, support it indefinitely, and remove this comment.  | 
7062  |  | */  | 
7063  |  |  | 
7064  |  | /*  | 
7065  |  | ** CAPI3REF: A Handle To An Open BLOB  | 
7066  |  | ** KEYWORDS: {BLOB handle} {BLOB handles} | 
7067  |  | **  | 
7068  |  | ** An instance of this object represents an open BLOB on which  | 
7069  |  | ** [sqlite3_blob_open | incremental BLOB I/O] can be performed.  | 
7070  |  | ** ^Objects of this type are created by [sqlite3_blob_open()]  | 
7071  |  | ** and destroyed by [sqlite3_blob_close()].  | 
7072  |  | ** ^The [sqlite3_blob_read()] and [sqlite3_blob_write()] interfaces  | 
7073  |  | ** can be used to read or write small subsections of the BLOB.  | 
7074  |  | ** ^The [sqlite3_blob_bytes()] interface returns the size of the BLOB in bytes.  | 
7075  |  | */  | 
7076  |  | typedef struct sqlite3_blob sqlite3_blob;  | 
7077  |  |  | 
7078  |  | /*  | 
7079  |  | ** CAPI3REF: Open A BLOB For Incremental I/O  | 
7080  |  | ** METHOD: sqlite3  | 
7081  |  | ** CONSTRUCTOR: sqlite3_blob  | 
7082  |  | **  | 
7083  |  | ** ^(This interfaces opens a [BLOB handle | handle] to the BLOB located  | 
7084  |  | ** in row iRow, column zColumn, table zTable in database zDb;  | 
7085  |  | ** in other words, the same BLOB that would be selected by:  | 
7086  |  | **  | 
7087  |  | ** <pre>  | 
7088  |  | **     SELECT zColumn FROM zDb.zTable WHERE [rowid] = iRow;  | 
7089  |  | ** </pre>)^  | 
7090  |  | **  | 
7091  |  | ** ^(Parameter zDb is not the filename that contains the database, but  | 
7092  |  | ** rather the symbolic name of the database. For attached databases, this is  | 
7093  |  | ** the name that appears after the AS keyword in the [ATTACH] statement.  | 
7094  |  | ** For the main database file, the database name is "main". For TEMP  | 
7095  |  | ** tables, the database name is "temp".)^  | 
7096  |  | **  | 
7097  |  | ** ^If the flags parameter is non-zero, then the BLOB is opened for read  | 
7098  |  | ** and write access. ^If the flags parameter is zero, the BLOB is opened for  | 
7099  |  | ** read-only access.  | 
7100  |  | **  | 
7101  |  | ** ^(On success, [SQLITE_OK] is returned and the new [BLOB handle] is stored  | 
7102  |  | ** in *ppBlob. Otherwise an [error code] is returned and, unless the error  | 
7103  |  | ** code is SQLITE_MISUSE, *ppBlob is set to NULL.)^ ^This means that, provided  | 
7104  |  | ** the API is not misused, it is always safe to call [sqlite3_blob_close()]  | 
7105  |  | ** on *ppBlob after this function it returns.  | 
7106  |  | **  | 
7107  |  | ** This function fails with SQLITE_ERROR if any of the following are true:  | 
7108  |  | ** <ul>  | 
7109  |  | **   <li> ^(Database zDb does not exist)^,  | 
7110  |  | **   <li> ^(Table zTable does not exist within database zDb)^,  | 
7111  |  | **   <li> ^(Table zTable is a WITHOUT ROWID table)^,  | 
7112  |  | **   <li> ^(Column zColumn does not exist)^,  | 
7113  |  | **   <li> ^(Row iRow is not present in the table)^,  | 
7114  |  | **   <li> ^(The specified column of row iRow contains a value that is not  | 
7115  |  | **         a TEXT or BLOB value)^,  | 
7116  |  | **   <li> ^(Column zColumn is part of an index, PRIMARY KEY or UNIQUE  | 
7117  |  | **         constraint and the blob is being opened for read/write access)^,  | 
7118  |  | **   <li> ^([foreign key constraints | Foreign key constraints] are enabled,  | 
7119  |  | **         column zColumn is part of a [child key] definition and the blob is  | 
7120  |  | **         being opened for read/write access)^.  | 
7121  |  | ** </ul>  | 
7122  |  | **  | 
7123  |  | ** ^Unless it returns SQLITE_MISUSE, this function sets the  | 
7124  |  | ** [database connection] error code and message accessible via  | 
7125  |  | ** [sqlite3_errcode()] and [sqlite3_errmsg()] and related functions.  | 
7126  |  | **  | 
7127  |  | ** A BLOB referenced by sqlite3_blob_open() may be read using the  | 
7128  |  | ** [sqlite3_blob_read()] interface and modified by using  | 
7129  |  | ** [sqlite3_blob_write()].  The [BLOB handle] can be moved to a  | 
7130  |  | ** different row of the same table using the [sqlite3_blob_reopen()]  | 
7131  |  | ** interface.  However, the column, table, or database of a [BLOB handle]  | 
7132  |  | ** cannot be changed after the [BLOB handle] is opened.  | 
7133  |  | **  | 
7134  |  | ** ^(If the row that a BLOB handle points to is modified by an  | 
7135  |  | ** [UPDATE], [DELETE], or by [ON CONFLICT] side-effects  | 
7136  |  | ** then the BLOB handle is marked as "expired".  | 
7137  |  | ** This is true if any column of the row is changed, even a column  | 
7138  |  | ** other than the one the BLOB handle is open on.)^  | 
7139  |  | ** ^Calls to [sqlite3_blob_read()] and [sqlite3_blob_write()] for  | 
7140  |  | ** an expired BLOB handle fail with a return code of [SQLITE_ABORT].  | 
7141  |  | ** ^(Changes written into a BLOB prior to the BLOB expiring are not  | 
7142  |  | ** rolled back by the expiration of the BLOB.  Such changes will eventually  | 
7143  |  | ** commit if the transaction continues to completion.)^  | 
7144  |  | **  | 
7145  |  | ** ^Use the [sqlite3_blob_bytes()] interface to determine the size of  | 
7146  |  | ** the opened blob.  ^The size of a blob may not be changed by this  | 
7147  |  | ** interface.  Use the [UPDATE] SQL command to change the size of a  | 
7148  |  | ** blob.  | 
7149  |  | **  | 
7150  |  | ** ^The [sqlite3_bind_zeroblob()] and [sqlite3_result_zeroblob()] interfaces  | 
7151  |  | ** and the built-in [zeroblob] SQL function may be used to create a  | 
7152  |  | ** zero-filled blob to read or write using the incremental-blob interface.  | 
7153  |  | **  | 
7154  |  | ** To avoid a resource leak, every open [BLOB handle] should eventually  | 
7155  |  | ** be released by a call to [sqlite3_blob_close()].  | 
7156  |  | **  | 
7157  |  | ** See also: [sqlite3_blob_close()],  | 
7158  |  | ** [sqlite3_blob_reopen()], [sqlite3_blob_read()],  | 
7159  |  | ** [sqlite3_blob_bytes()], [sqlite3_blob_write()].  | 
7160  |  | */  | 
7161  |  | SQLITE_API int sqlite3_blob_open(  | 
7162  |  |   sqlite3*,  | 
7163  |  |   const char *zDb,  | 
7164  |  |   const char *zTable,  | 
7165  |  |   const char *zColumn,  | 
7166  |  |   sqlite3_int64 iRow,  | 
7167  |  |   int flags,  | 
7168  |  |   sqlite3_blob **ppBlob  | 
7169  |  | );  | 
7170  |  |  | 
7171  |  | /*  | 
7172  |  | ** CAPI3REF: Move a BLOB Handle to a New Row  | 
7173  |  | ** METHOD: sqlite3_blob  | 
7174  |  | **  | 
7175  |  | ** ^This function is used to move an existing [BLOB handle] so that it points  | 
7176  |  | ** to a different row of the same database table. ^The new row is identified  | 
7177  |  | ** by the rowid value passed as the second argument. Only the row can be  | 
7178  |  | ** changed. ^The database, table and column on which the blob handle is open  | 
7179  |  | ** remain the same. Moving an existing [BLOB handle] to a new row is  | 
7180  |  | ** faster than closing the existing handle and opening a new one.  | 
7181  |  | **  | 
7182  |  | ** ^(The new row must meet the same criteria as for [sqlite3_blob_open()] -  | 
7183  |  | ** it must exist and there must be either a blob or text value stored in  | 
7184  |  | ** the nominated column.)^ ^If the new row is not present in the table, or if  | 
7185  |  | ** it does not contain a blob or text value, or if another error occurs, an  | 
7186  |  | ** SQLite error code is returned and the blob handle is considered aborted.  | 
7187  |  | ** ^All subsequent calls to [sqlite3_blob_read()], [sqlite3_blob_write()] or  | 
7188  |  | ** [sqlite3_blob_reopen()] on an aborted blob handle immediately return  | 
7189  |  | ** SQLITE_ABORT. ^Calling [sqlite3_blob_bytes()] on an aborted blob handle  | 
7190  |  | ** always returns zero.  | 
7191  |  | **  | 
7192  |  | ** ^This function sets the database handle error code and message.  | 
7193  |  | */  | 
7194  |  | SQLITE_API int sqlite3_blob_reopen(sqlite3_blob *, sqlite3_int64);  | 
7195  |  |  | 
7196  |  | /*  | 
7197  |  | ** CAPI3REF: Close A BLOB Handle  | 
7198  |  | ** DESTRUCTOR: sqlite3_blob  | 
7199  |  | **  | 
7200  |  | ** ^This function closes an open [BLOB handle]. ^(The BLOB handle is closed  | 
7201  |  | ** unconditionally.  Even if this routine returns an error code, the  | 
7202  |  | ** handle is still closed.)^  | 
7203  |  | **  | 
7204  |  | ** ^If the blob handle being closed was opened for read-write access, and if  | 
7205  |  | ** the database is in auto-commit mode and there are no other open read-write  | 
7206  |  | ** blob handles or active write statements, the current transaction is  | 
7207  |  | ** committed. ^If an error occurs while committing the transaction, an error  | 
7208  |  | ** code is returned and the transaction rolled back.  | 
7209  |  | **  | 
7210  |  | ** Calling this function with an argument that is not a NULL pointer or an  | 
7211  |  | ** open blob handle results in undefined behaviour. ^Calling this routine  | 
7212  |  | ** with a null pointer (such as would be returned by a failed call to  | 
7213  |  | ** [sqlite3_blob_open()]) is a harmless no-op. ^Otherwise, if this function  | 
7214  |  | ** is passed a valid open blob handle, the values returned by the  | 
7215  |  | ** sqlite3_errcode() and sqlite3_errmsg() functions are set before returning.  | 
7216  |  | */  | 
7217  |  | SQLITE_API int sqlite3_blob_close(sqlite3_blob *);  | 
7218  |  |  | 
7219  |  | /*  | 
7220  |  | ** CAPI3REF: Return The Size Of An Open BLOB  | 
7221  |  | ** METHOD: sqlite3_blob  | 
7222  |  | **  | 
7223  |  | ** ^Returns the size in bytes of the BLOB accessible via the  | 
7224  |  | ** successfully opened [BLOB handle] in its only argument.  ^The  | 
7225  |  | ** incremental blob I/O routines can only read or overwriting existing  | 
7226  |  | ** blob content; they cannot change the size of a blob.  | 
7227  |  | **  | 
7228  |  | ** This routine only works on a [BLOB handle] which has been created  | 
7229  |  | ** by a prior successful call to [sqlite3_blob_open()] and which has not  | 
7230  |  | ** been closed by [sqlite3_blob_close()].  Passing any other pointer in  | 
7231  |  | ** to this routine results in undefined and probably undesirable behavior.  | 
7232  |  | */  | 
7233  |  | SQLITE_API int sqlite3_blob_bytes(sqlite3_blob *);  | 
7234  |  |  | 
7235  |  | /*  | 
7236  |  | ** CAPI3REF: Read Data From A BLOB Incrementally  | 
7237  |  | ** METHOD: sqlite3_blob  | 
7238  |  | **  | 
7239  |  | ** ^(This function is used to read data from an open [BLOB handle] into a  | 
7240  |  | ** caller-supplied buffer. N bytes of data are copied into buffer Z  | 
7241  |  | ** from the open BLOB, starting at offset iOffset.)^  | 
7242  |  | **  | 
7243  |  | ** ^If offset iOffset is less than N bytes from the end of the BLOB,  | 
7244  |  | ** [SQLITE_ERROR] is returned and no data is read.  ^If N or iOffset is  | 
7245  |  | ** less than zero, [SQLITE_ERROR] is returned and no data is read.  | 
7246  |  | ** ^The size of the blob (and hence the maximum value of N+iOffset)  | 
7247  |  | ** can be determined using the [sqlite3_blob_bytes()] interface.  | 
7248  |  | **  | 
7249  |  | ** ^An attempt to read from an expired [BLOB handle] fails with an  | 
7250  |  | ** error code of [SQLITE_ABORT].  | 
7251  |  | **  | 
7252  |  | ** ^(On success, sqlite3_blob_read() returns SQLITE_OK.  | 
7253  |  | ** Otherwise, an [error code] or an [extended error code] is returned.)^  | 
7254  |  | **  | 
7255  |  | ** This routine only works on a [BLOB handle] which has been created  | 
7256  |  | ** by a prior successful call to [sqlite3_blob_open()] and which has not  | 
7257  |  | ** been closed by [sqlite3_blob_close()].  Passing any other pointer in  | 
7258  |  | ** to this routine results in undefined and probably undesirable behavior.  | 
7259  |  | **  | 
7260  |  | ** See also: [sqlite3_blob_write()].  | 
7261  |  | */  | 
7262  |  | SQLITE_API int sqlite3_blob_read(sqlite3_blob *, void *Z, int N, int iOffset);  | 
7263  |  |  | 
7264  |  | /*  | 
7265  |  | ** CAPI3REF: Write Data Into A BLOB Incrementally  | 
7266  |  | ** METHOD: sqlite3_blob  | 
7267  |  | **  | 
7268  |  | ** ^(This function is used to write data into an open [BLOB handle] from a  | 
7269  |  | ** caller-supplied buffer. N bytes of data are copied from the buffer Z  | 
7270  |  | ** into the open BLOB, starting at offset iOffset.)^  | 
7271  |  | **  | 
7272  |  | ** ^(On success, sqlite3_blob_write() returns SQLITE_OK.  | 
7273  |  | ** Otherwise, an  [error code] or an [extended error code] is returned.)^  | 
7274  |  | ** ^Unless SQLITE_MISUSE is returned, this function sets the  | 
7275  |  | ** [database connection] error code and message accessible via  | 
7276  |  | ** [sqlite3_errcode()] and [sqlite3_errmsg()] and related functions.  | 
7277  |  | **  | 
7278  |  | ** ^If the [BLOB handle] passed as the first argument was not opened for  | 
7279  |  | ** writing (the flags parameter to [sqlite3_blob_open()] was zero),  | 
7280  |  | ** this function returns [SQLITE_READONLY].  | 
7281  |  | **  | 
7282  |  | ** This function may only modify the contents of the BLOB; it is  | 
7283  |  | ** not possible to increase the size of a BLOB using this API.  | 
7284  |  | ** ^If offset iOffset is less than N bytes from the end of the BLOB,  | 
7285  |  | ** [SQLITE_ERROR] is returned and no data is written. The size of the  | 
7286  |  | ** BLOB (and hence the maximum value of N+iOffset) can be determined  | 
7287  |  | ** using the [sqlite3_blob_bytes()] interface. ^If N or iOffset are less  | 
7288  |  | ** than zero [SQLITE_ERROR] is returned and no data is written.  | 
7289  |  | **  | 
7290  |  | ** ^An attempt to write to an expired [BLOB handle] fails with an  | 
7291  |  | ** error code of [SQLITE_ABORT].  ^Writes to the BLOB that occurred  | 
7292  |  | ** before the [BLOB handle] expired are not rolled back by the  | 
7293  |  | ** expiration of the handle, though of course those changes might  | 
7294  |  | ** have been overwritten by the statement that expired the BLOB handle  | 
7295  |  | ** or by other independent statements.  | 
7296  |  | **  | 
7297  |  | ** This routine only works on a [BLOB handle] which has been created  | 
7298  |  | ** by a prior successful call to [sqlite3_blob_open()] and which has not  | 
7299  |  | ** been closed by [sqlite3_blob_close()].  Passing any other pointer in  | 
7300  |  | ** to this routine results in undefined and probably undesirable behavior.  | 
7301  |  | **  | 
7302  |  | ** See also: [sqlite3_blob_read()].  | 
7303  |  | */  | 
7304  |  | SQLITE_API int sqlite3_blob_write(sqlite3_blob *, const void *z, int n, int iOffset);  | 
7305  |  |  | 
7306  |  | /*  | 
7307  |  | ** CAPI3REF: Virtual File System Objects  | 
7308  |  | **  | 
7309  |  | ** A virtual filesystem (VFS) is an [sqlite3_vfs] object  | 
7310  |  | ** that SQLite uses to interact  | 
7311  |  | ** with the underlying operating system.  Most SQLite builds come with a  | 
7312  |  | ** single default VFS that is appropriate for the host computer.  | 
7313  |  | ** New VFSes can be registered and existing VFSes can be unregistered.  | 
7314  |  | ** The following interfaces are provided.  | 
7315  |  | **  | 
7316  |  | ** ^The sqlite3_vfs_find() interface returns a pointer to a VFS given its name.  | 
7317  |  | ** ^Names are case sensitive.  | 
7318  |  | ** ^Names are zero-terminated UTF-8 strings.  | 
7319  |  | ** ^If there is no match, a NULL pointer is returned.  | 
7320  |  | ** ^If zVfsName is NULL then the default VFS is returned.  | 
7321  |  | **  | 
7322  |  | ** ^New VFSes are registered with sqlite3_vfs_register().  | 
7323  |  | ** ^Each new VFS becomes the default VFS if the makeDflt flag is set.  | 
7324  |  | ** ^The same VFS can be registered multiple times without injury.  | 
7325  |  | ** ^To make an existing VFS into the default VFS, register it again  | 
7326  |  | ** with the makeDflt flag set.  If two different VFSes with the  | 
7327  |  | ** same name are registered, the behavior is undefined.  If a  | 
7328  |  | ** VFS is registered with a name that is NULL or an empty string,  | 
7329  |  | ** then the behavior is undefined.  | 
7330  |  | **  | 
7331  |  | ** ^Unregister a VFS with the sqlite3_vfs_unregister() interface.  | 
7332  |  | ** ^(If the default VFS is unregistered, another VFS is chosen as  | 
7333  |  | ** the default.  The choice for the new VFS is arbitrary.)^  | 
7334  |  | */  | 
7335  |  | SQLITE_API sqlite3_vfs *sqlite3_vfs_find(const char *zVfsName);  | 
7336  |  | SQLITE_API int sqlite3_vfs_register(sqlite3_vfs*, int makeDflt);  | 
7337  |  | SQLITE_API int sqlite3_vfs_unregister(sqlite3_vfs*);  | 
7338  |  |  | 
7339  |  | /*  | 
7340  |  | ** CAPI3REF: Mutexes  | 
7341  |  | **  | 
7342  |  | ** The SQLite core uses these routines for thread  | 
7343  |  | ** synchronization. Though they are intended for internal  | 
7344  |  | ** use by SQLite, code that links against SQLite is  | 
7345  |  | ** permitted to use any of these routines.  | 
7346  |  | **  | 
7347  |  | ** The SQLite source code contains multiple implementations  | 
7348  |  | ** of these mutex routines.  An appropriate implementation  | 
7349  |  | ** is selected automatically at compile-time.  The following  | 
7350  |  | ** implementations are available in the SQLite core:  | 
7351  |  | **  | 
7352  |  | ** <ul>  | 
7353  |  | ** <li>   SQLITE_MUTEX_PTHREADS  | 
7354  |  | ** <li>   SQLITE_MUTEX_W32  | 
7355  |  | ** <li>   SQLITE_MUTEX_NOOP  | 
7356  |  | ** </ul>  | 
7357  |  | **  | 
7358  |  | ** The SQLITE_MUTEX_NOOP implementation is a set of routines  | 
7359  |  | ** that does no real locking and is appropriate for use in  | 
7360  |  | ** a single-threaded application.  The SQLITE_MUTEX_PTHREADS and  | 
7361  |  | ** SQLITE_MUTEX_W32 implementations are appropriate for use on Unix  | 
7362  |  | ** and Windows.  | 
7363  |  | **  | 
7364  |  | ** If SQLite is compiled with the SQLITE_MUTEX_APPDEF preprocessor  | 
7365  |  | ** macro defined (with "-DSQLITE_MUTEX_APPDEF=1"), then no mutex  | 
7366  |  | ** implementation is included with the library. In this case the  | 
7367  |  | ** application must supply a custom mutex implementation using the  | 
7368  |  | ** [SQLITE_CONFIG_MUTEX] option of the sqlite3_config() function  | 
7369  |  | ** before calling sqlite3_initialize() or any other public sqlite3_  | 
7370  |  | ** function that calls sqlite3_initialize().  | 
7371  |  | **  | 
7372  |  | ** ^The sqlite3_mutex_alloc() routine allocates a new  | 
7373  |  | ** mutex and returns a pointer to it. ^The sqlite3_mutex_alloc()  | 
7374  |  | ** routine returns NULL if it is unable to allocate the requested  | 
7375  |  | ** mutex.  The argument to sqlite3_mutex_alloc() must one of these  | 
7376  |  | ** integer constants:  | 
7377  |  | **  | 
7378  |  | ** <ul>  | 
7379  |  | ** <li>  SQLITE_MUTEX_FAST  | 
7380  |  | ** <li>  SQLITE_MUTEX_RECURSIVE  | 
7381  |  | ** <li>  SQLITE_MUTEX_STATIC_MAIN  | 
7382  |  | ** <li>  SQLITE_MUTEX_STATIC_MEM  | 
7383  |  | ** <li>  SQLITE_MUTEX_STATIC_OPEN  | 
7384  |  | ** <li>  SQLITE_MUTEX_STATIC_PRNG  | 
7385  |  | ** <li>  SQLITE_MUTEX_STATIC_LRU  | 
7386  |  | ** <li>  SQLITE_MUTEX_STATIC_PMEM  | 
7387  |  | ** <li>  SQLITE_MUTEX_STATIC_APP1  | 
7388  |  | ** <li>  SQLITE_MUTEX_STATIC_APP2  | 
7389  |  | ** <li>  SQLITE_MUTEX_STATIC_APP3  | 
7390  |  | ** <li>  SQLITE_MUTEX_STATIC_VFS1  | 
7391  |  | ** <li>  SQLITE_MUTEX_STATIC_VFS2  | 
7392  |  | ** <li>  SQLITE_MUTEX_STATIC_VFS3  | 
7393  |  | ** </ul>  | 
7394  |  | **  | 
7395  |  | ** ^The first two constants (SQLITE_MUTEX_FAST and SQLITE_MUTEX_RECURSIVE)  | 
7396  |  | ** cause sqlite3_mutex_alloc() to create  | 
7397  |  | ** a new mutex.  ^The new mutex is recursive when SQLITE_MUTEX_RECURSIVE  | 
7398  |  | ** is used but not necessarily so when SQLITE_MUTEX_FAST is used.  | 
7399  |  | ** The mutex implementation does not need to make a distinction  | 
7400  |  | ** between SQLITE_MUTEX_RECURSIVE and SQLITE_MUTEX_FAST if it does  | 
7401  |  | ** not want to.  SQLite will only request a recursive mutex in  | 
7402  |  | ** cases where it really needs one.  If a faster non-recursive mutex  | 
7403  |  | ** implementation is available on the host platform, the mutex subsystem  | 
7404  |  | ** might return such a mutex in response to SQLITE_MUTEX_FAST.  | 
7405  |  | **  | 
7406  |  | ** ^The other allowed parameters to sqlite3_mutex_alloc() (anything other  | 
7407  |  | ** than SQLITE_MUTEX_FAST and SQLITE_MUTEX_RECURSIVE) each return  | 
7408  |  | ** a pointer to a static preexisting mutex.  ^Nine static mutexes are  | 
7409  |  | ** used by the current version of SQLite.  Future versions of SQLite  | 
7410  |  | ** may add additional static mutexes.  Static mutexes are for internal  | 
7411  |  | ** use by SQLite only.  Applications that use SQLite mutexes should  | 
7412  |  | ** use only the dynamic mutexes returned by SQLITE_MUTEX_FAST or  | 
7413  |  | ** SQLITE_MUTEX_RECURSIVE.  | 
7414  |  | **  | 
7415  |  | ** ^Note that if one of the dynamic mutex parameters (SQLITE_MUTEX_FAST  | 
7416  |  | ** or SQLITE_MUTEX_RECURSIVE) is used then sqlite3_mutex_alloc()  | 
7417  |  | ** returns a different mutex on every call.  ^For the static  | 
7418  |  | ** mutex types, the same mutex is returned on every call that has  | 
7419  |  | ** the same type number.  | 
7420  |  | **  | 
7421  |  | ** ^The sqlite3_mutex_free() routine deallocates a previously  | 
7422  |  | ** allocated dynamic mutex.  Attempting to deallocate a static  | 
7423  |  | ** mutex results in undefined behavior.  | 
7424  |  | **  | 
7425  |  | ** ^The sqlite3_mutex_enter() and sqlite3_mutex_try() routines attempt  | 
7426  |  | ** to enter a mutex.  ^If another thread is already within the mutex,  | 
7427  |  | ** sqlite3_mutex_enter() will block and sqlite3_mutex_try() will return  | 
7428  |  | ** SQLITE_BUSY.  ^The sqlite3_mutex_try() interface returns [SQLITE_OK]  | 
7429  |  | ** upon successful entry.  ^(Mutexes created using  | 
7430  |  | ** SQLITE_MUTEX_RECURSIVE can be entered multiple times by the same thread.  | 
7431  |  | ** In such cases, the  | 
7432  |  | ** mutex must be exited an equal number of times before another thread  | 
7433  |  | ** can enter.)^  If the same thread tries to enter any mutex other  | 
7434  |  | ** than an SQLITE_MUTEX_RECURSIVE more than once, the behavior is undefined.  | 
7435  |  | **  | 
7436  |  | ** ^(Some systems (for example, Windows 95) do not support the operation  | 
7437  |  | ** implemented by sqlite3_mutex_try().  On those systems, sqlite3_mutex_try()  | 
7438  |  | ** will always return SQLITE_BUSY. The SQLite core only ever uses  | 
7439  |  | ** sqlite3_mutex_try() as an optimization so this is acceptable  | 
7440  |  | ** behavior.)^  | 
7441  |  | **  | 
7442  |  | ** ^The sqlite3_mutex_leave() routine exits a mutex that was  | 
7443  |  | ** previously entered by the same thread.   The behavior  | 
7444  |  | ** is undefined if the mutex is not currently entered by the  | 
7445  |  | ** calling thread or is not currently allocated.  | 
7446  |  | **  | 
7447  |  | ** ^If the argument to sqlite3_mutex_enter(), sqlite3_mutex_try(), or  | 
7448  |  | ** sqlite3_mutex_leave() is a NULL pointer, then all three routines  | 
7449  |  | ** behave as no-ops.  | 
7450  |  | **  | 
7451  |  | ** See also: [sqlite3_mutex_held()] and [sqlite3_mutex_notheld()].  | 
7452  |  | */  | 
7453  |  | SQLITE_API sqlite3_mutex *sqlite3_mutex_alloc(int);  | 
7454  |  | SQLITE_API void sqlite3_mutex_free(sqlite3_mutex*);  | 
7455  |  | SQLITE_API void sqlite3_mutex_enter(sqlite3_mutex*);  | 
7456  |  | SQLITE_API int sqlite3_mutex_try(sqlite3_mutex*);  | 
7457  |  | SQLITE_API void sqlite3_mutex_leave(sqlite3_mutex*);  | 
7458  |  |  | 
7459  |  | /*  | 
7460  |  | ** CAPI3REF: Mutex Methods Object  | 
7461  |  | **  | 
7462  |  | ** An instance of this structure defines the low-level routines  | 
7463  |  | ** used to allocate and use mutexes.  | 
7464  |  | **  | 
7465  |  | ** Usually, the default mutex implementations provided by SQLite are  | 
7466  |  | ** sufficient, however the application has the option of substituting a custom  | 
7467  |  | ** implementation for specialized deployments or systems for which SQLite  | 
7468  |  | ** does not provide a suitable implementation. In this case, the application  | 
7469  |  | ** creates and populates an instance of this structure to pass  | 
7470  |  | ** to sqlite3_config() along with the [SQLITE_CONFIG_MUTEX] option.  | 
7471  |  | ** Additionally, an instance of this structure can be used as an  | 
7472  |  | ** output variable when querying the system for the current mutex  | 
7473  |  | ** implementation, using the [SQLITE_CONFIG_GETMUTEX] option.  | 
7474  |  | **  | 
7475  |  | ** ^The xMutexInit method defined by this structure is invoked as  | 
7476  |  | ** part of system initialization by the sqlite3_initialize() function.  | 
7477  |  | ** ^The xMutexInit routine is called by SQLite exactly once for each  | 
7478  |  | ** effective call to [sqlite3_initialize()].  | 
7479  |  | **  | 
7480  |  | ** ^The xMutexEnd method defined by this structure is invoked as  | 
7481  |  | ** part of system shutdown by the sqlite3_shutdown() function. The  | 
7482  |  | ** implementation of this method is expected to release all outstanding  | 
7483  |  | ** resources obtained by the mutex methods implementation, especially  | 
7484  |  | ** those obtained by the xMutexInit method.  ^The xMutexEnd()  | 
7485  |  | ** interface is invoked exactly once for each call to [sqlite3_shutdown()].  | 
7486  |  | **  | 
7487  |  | ** ^(The remaining seven methods defined by this structure (xMutexAlloc,  | 
7488  |  | ** xMutexFree, xMutexEnter, xMutexTry, xMutexLeave, xMutexHeld and  | 
7489  |  | ** xMutexNotheld) implement the following interfaces (respectively):  | 
7490  |  | **  | 
7491  |  | ** <ul>  | 
7492  |  | **   <li>  [sqlite3_mutex_alloc()] </li>  | 
7493  |  | **   <li>  [sqlite3_mutex_free()] </li>  | 
7494  |  | **   <li>  [sqlite3_mutex_enter()] </li>  | 
7495  |  | **   <li>  [sqlite3_mutex_try()] </li>  | 
7496  |  | **   <li>  [sqlite3_mutex_leave()] </li>  | 
7497  |  | **   <li>  [sqlite3_mutex_held()] </li>  | 
7498  |  | **   <li>  [sqlite3_mutex_notheld()] </li>  | 
7499  |  | ** </ul>)^  | 
7500  |  | **  | 
7501  |  | ** The only difference is that the public sqlite3_XXX functions enumerated  | 
7502  |  | ** above silently ignore any invocations that pass a NULL pointer instead  | 
7503  |  | ** of a valid mutex handle. The implementations of the methods defined  | 
7504  |  | ** by this structure are not required to handle this case. The results  | 
7505  |  | ** of passing a NULL pointer instead of a valid mutex handle are undefined  | 
7506  |  | ** (i.e. it is acceptable to provide an implementation that segfaults if  | 
7507  |  | ** it is passed a NULL pointer).  | 
7508  |  | **  | 
7509  |  | ** The xMutexInit() method must be threadsafe.  It must be harmless to  | 
7510  |  | ** invoke xMutexInit() multiple times within the same process and without  | 
7511  |  | ** intervening calls to xMutexEnd().  Second and subsequent calls to  | 
7512  |  | ** xMutexInit() must be no-ops.  | 
7513  |  | **  | 
7514  |  | ** xMutexInit() must not use SQLite memory allocation ([sqlite3_malloc()]  | 
7515  |  | ** and its associates).  Similarly, xMutexAlloc() must not use SQLite memory  | 
7516  |  | ** allocation for a static mutex.  ^However xMutexAlloc() may use SQLite  | 
7517  |  | ** memory allocation for a fast or recursive mutex.  | 
7518  |  | **  | 
7519  |  | ** ^SQLite will invoke the xMutexEnd() method when [sqlite3_shutdown()] is  | 
7520  |  | ** called, but only if the prior call to xMutexInit returned SQLITE_OK.  | 
7521  |  | ** If xMutexInit fails in any way, it is expected to clean up after itself  | 
7522  |  | ** prior to returning.  | 
7523  |  | */  | 
7524  |  | typedef struct sqlite3_mutex_methods sqlite3_mutex_methods;  | 
7525  |  | struct sqlite3_mutex_methods { | 
7526  |  |   int (*xMutexInit)(void);  | 
7527  |  |   int (*xMutexEnd)(void);  | 
7528  |  |   sqlite3_mutex *(*xMutexAlloc)(int);  | 
7529  |  |   void (*xMutexFree)(sqlite3_mutex *);  | 
7530  |  |   void (*xMutexEnter)(sqlite3_mutex *);  | 
7531  |  |   int (*xMutexTry)(sqlite3_mutex *);  | 
7532  |  |   void (*xMutexLeave)(sqlite3_mutex *);  | 
7533  |  |   int (*xMutexHeld)(sqlite3_mutex *);  | 
7534  |  |   int (*xMutexNotheld)(sqlite3_mutex *);  | 
7535  |  | };  | 
7536  |  |  | 
7537  |  | /*  | 
7538  |  | ** CAPI3REF: Mutex Verification Routines  | 
7539  |  | **  | 
7540  |  | ** The sqlite3_mutex_held() and sqlite3_mutex_notheld() routines  | 
7541  |  | ** are intended for use inside assert() statements.  The SQLite core  | 
7542  |  | ** never uses these routines except inside an assert() and applications  | 
7543  |  | ** are advised to follow the lead of the core.  The SQLite core only  | 
7544  |  | ** provides implementations for these routines when it is compiled  | 
7545  |  | ** with the SQLITE_DEBUG flag.  External mutex implementations  | 
7546  |  | ** are only required to provide these routines if SQLITE_DEBUG is  | 
7547  |  | ** defined and if NDEBUG is not defined.  | 
7548  |  | **  | 
7549  |  | ** These routines should return true if the mutex in their argument  | 
7550  |  | ** is held or not held, respectively, by the calling thread.  | 
7551  |  | **  | 
7552  |  | ** The implementation is not required to provide versions of these  | 
7553  |  | ** routines that actually work. If the implementation does not provide working  | 
7554  |  | ** versions of these routines, it should at least provide stubs that always  | 
7555  |  | ** return true so that one does not get spurious assertion failures.  | 
7556  |  | **  | 
7557  |  | ** If the argument to sqlite3_mutex_held() is a NULL pointer then  | 
7558  |  | ** the routine should return 1.   This seems counter-intuitive since  | 
7559  |  | ** clearly the mutex cannot be held if it does not exist.  But  | 
7560  |  | ** the reason the mutex does not exist is because the build is not  | 
7561  |  | ** using mutexes.  And we do not want the assert() containing the  | 
7562  |  | ** call to sqlite3_mutex_held() to fail, so a non-zero return is  | 
7563  |  | ** the appropriate thing to do.  The sqlite3_mutex_notheld()  | 
7564  |  | ** interface should also return 1 when given a NULL pointer.  | 
7565  |  | */  | 
7566  |  | #ifndef NDEBUG  | 
7567  |  | SQLITE_API int sqlite3_mutex_held(sqlite3_mutex*);  | 
7568  |  | SQLITE_API int sqlite3_mutex_notheld(sqlite3_mutex*);  | 
7569  |  | #endif  | 
7570  |  |  | 
7571  |  | /*  | 
7572  |  | ** CAPI3REF: Mutex Types  | 
7573  |  | **  | 
7574  |  | ** The [sqlite3_mutex_alloc()] interface takes a single argument  | 
7575  |  | ** which is one of these integer constants.  | 
7576  |  | **  | 
7577  |  | ** The set of static mutexes may change from one SQLite release to the  | 
7578  |  | ** next.  Applications that override the built-in mutex logic must be  | 
7579  |  | ** prepared to accommodate additional static mutexes.  | 
7580  |  | */  | 
7581  |  | #define SQLITE_MUTEX_FAST             0  | 
7582  |  | #define SQLITE_MUTEX_RECURSIVE        1  | 
7583  |  | #define SQLITE_MUTEX_STATIC_MAIN      2  | 
7584  |  | #define SQLITE_MUTEX_STATIC_MEM       3  /* sqlite3_malloc() */  | 
7585  |  | #define SQLITE_MUTEX_STATIC_MEM2      4  /* NOT USED */  | 
7586  |  | #define SQLITE_MUTEX_STATIC_OPEN      4  /* sqlite3BtreeOpen() */  | 
7587  |  | #define SQLITE_MUTEX_STATIC_PRNG      5  /* sqlite3_randomness() */  | 
7588  |  | #define SQLITE_MUTEX_STATIC_LRU       6  /* lru page list */  | 
7589  |  | #define SQLITE_MUTEX_STATIC_LRU2      7  /* NOT USED */  | 
7590  |  | #define SQLITE_MUTEX_STATIC_PMEM      7  /* sqlite3PageMalloc() */  | 
7591  |  | #define SQLITE_MUTEX_STATIC_APP1      8  /* For use by application */  | 
7592  |  | #define SQLITE_MUTEX_STATIC_APP2      9  /* For use by application */  | 
7593  |  | #define SQLITE_MUTEX_STATIC_APP3     10  /* For use by application */  | 
7594  |  | #define SQLITE_MUTEX_STATIC_VFS1     11  /* For use by built-in VFS */  | 
7595  |  | #define SQLITE_MUTEX_STATIC_VFS2     12  /* For use by extension VFS */  | 
7596  |  | #define SQLITE_MUTEX_STATIC_VFS3     13  /* For use by application VFS */  | 
7597  |  |  | 
7598  |  | /* Legacy compatibility: */  | 
7599  |  | #define SQLITE_MUTEX_STATIC_MASTER    2  | 
7600  |  |  | 
7601  |  |  | 
7602  |  | /*  | 
7603  |  | ** CAPI3REF: Retrieve the mutex for a database connection  | 
7604  |  | ** METHOD: sqlite3  | 
7605  |  | **  | 
7606  |  | ** ^This interface returns a pointer the [sqlite3_mutex] object that  | 
7607  |  | ** serializes access to the [database connection] given in the argument  | 
7608  |  | ** when the [threading mode] is Serialized.  | 
7609  |  | ** ^If the [threading mode] is Single-thread or Multi-thread then this  | 
7610  |  | ** routine returns a NULL pointer.  | 
7611  |  | */  | 
7612  |  | SQLITE_API sqlite3_mutex *sqlite3_db_mutex(sqlite3*);  | 
7613  |  |  | 
7614  |  | /*  | 
7615  |  | ** CAPI3REF: Low-Level Control Of Database Files  | 
7616  |  | ** METHOD: sqlite3  | 
7617  |  | ** KEYWORDS: {file control} | 
7618  |  | **  | 
7619  |  | ** ^The [sqlite3_file_control()] interface makes a direct call to the  | 
7620  |  | ** xFileControl method for the [sqlite3_io_methods] object associated  | 
7621  |  | ** with a particular database identified by the second argument. ^The  | 
7622  |  | ** name of the database is "main" for the main database or "temp" for the  | 
7623  |  | ** TEMP database, or the name that appears after the AS keyword for  | 
7624  |  | ** databases that are added using the [ATTACH] SQL command.  | 
7625  |  | ** ^A NULL pointer can be used in place of "main" to refer to the  | 
7626  |  | ** main database file.  | 
7627  |  | ** ^The third and fourth parameters to this routine  | 
7628  |  | ** are passed directly through to the second and third parameters of  | 
7629  |  | ** the xFileControl method.  ^The return value of the xFileControl  | 
7630  |  | ** method becomes the return value of this routine.  | 
7631  |  | **  | 
7632  |  | ** A few opcodes for [sqlite3_file_control()] are handled directly  | 
7633  |  | ** by the SQLite core and never invoke the  | 
7634  |  | ** sqlite3_io_methods.xFileControl method.  | 
7635  |  | ** ^The [SQLITE_FCNTL_FILE_POINTER] value for the op parameter causes  | 
7636  |  | ** a pointer to the underlying [sqlite3_file] object to be written into  | 
7637  |  | ** the space pointed to by the 4th parameter.  The  | 
7638  |  | ** [SQLITE_FCNTL_JOURNAL_POINTER] works similarly except that it returns  | 
7639  |  | ** the [sqlite3_file] object associated with the journal file instead of  | 
7640  |  | ** the main database.  The [SQLITE_FCNTL_VFS_POINTER] opcode returns  | 
7641  |  | ** a pointer to the underlying [sqlite3_vfs] object for the file.  | 
7642  |  | ** The [SQLITE_FCNTL_DATA_VERSION] returns the data version counter  | 
7643  |  | ** from the pager.  | 
7644  |  | **  | 
7645  |  | ** ^If the second parameter (zDbName) does not match the name of any  | 
7646  |  | ** open database file, then SQLITE_ERROR is returned.  ^This error  | 
7647  |  | ** code is not remembered and will not be recalled by [sqlite3_errcode()]  | 
7648  |  | ** or [sqlite3_errmsg()].  The underlying xFileControl method might  | 
7649  |  | ** also return SQLITE_ERROR.  There is no way to distinguish between  | 
7650  |  | ** an incorrect zDbName and an SQLITE_ERROR return from the underlying  | 
7651  |  | ** xFileControl method.  | 
7652  |  | **  | 
7653  |  | ** See also: [file control opcodes]  | 
7654  |  | */  | 
7655  |  | SQLITE_API int sqlite3_file_control(sqlite3*, const char *zDbName, int op, void*);  | 
7656  |  |  | 
7657  |  | /*  | 
7658  |  | ** CAPI3REF: Testing Interface  | 
7659  |  | **  | 
7660  |  | ** ^The sqlite3_test_control() interface is used to read out internal  | 
7661  |  | ** state of SQLite and to inject faults into SQLite for testing  | 
7662  |  | ** purposes.  ^The first parameter is an operation code that determines  | 
7663  |  | ** the number, meaning, and operation of all subsequent parameters.  | 
7664  |  | **  | 
7665  |  | ** This interface is not for use by applications.  It exists solely  | 
7666  |  | ** for verifying the correct operation of the SQLite library.  Depending  | 
7667  |  | ** on how the SQLite library is compiled, this interface might not exist.  | 
7668  |  | **  | 
7669  |  | ** The details of the operation codes, their meanings, the parameters  | 
7670  |  | ** they take, and what they do are all subject to change without notice.  | 
7671  |  | ** Unlike most of the SQLite API, this function is not guaranteed to  | 
7672  |  | ** operate consistently from one release to the next.  | 
7673  |  | */  | 
7674  |  | SQLITE_API int sqlite3_test_control(int op, ...);  | 
7675  |  |  | 
7676  |  | /*  | 
7677  |  | ** CAPI3REF: Testing Interface Operation Codes  | 
7678  |  | **  | 
7679  |  | ** These constants are the valid operation code parameters used  | 
7680  |  | ** as the first argument to [sqlite3_test_control()].  | 
7681  |  | **  | 
7682  |  | ** These parameters and their meanings are subject to change  | 
7683  |  | ** without notice.  These values are for testing purposes only.  | 
7684  |  | ** Applications should not use any of these parameters or the  | 
7685  |  | ** [sqlite3_test_control()] interface.  | 
7686  |  | */  | 
7687  |  | #define SQLITE_TESTCTRL_FIRST                    5  | 
7688  |  | #define SQLITE_TESTCTRL_PRNG_SAVE                5  | 
7689  |  | #define SQLITE_TESTCTRL_PRNG_RESTORE             6  | 
7690  |  | #define SQLITE_TESTCTRL_PRNG_RESET               7  /* NOT USED */  | 
7691  |  | #define SQLITE_TESTCTRL_BITVEC_TEST              8  | 
7692  |  | #define SQLITE_TESTCTRL_FAULT_INSTALL            9  | 
7693  |  | #define SQLITE_TESTCTRL_BENIGN_MALLOC_HOOKS     10  | 
7694  |  | #define SQLITE_TESTCTRL_PENDING_BYTE            11  | 
7695  |  | #define SQLITE_TESTCTRL_ASSERT                  12  | 
7696  |  | #define SQLITE_TESTCTRL_ALWAYS                  13  | 
7697  |  | #define SQLITE_TESTCTRL_RESERVE                 14  /* NOT USED */  | 
7698  |  | #define SQLITE_TESTCTRL_OPTIMIZATIONS           15  | 
7699  |  | #define SQLITE_TESTCTRL_ISKEYWORD               16  /* NOT USED */  | 
7700  |  | #define SQLITE_TESTCTRL_SCRATCHMALLOC           17  /* NOT USED */  | 
7701  |  | #define SQLITE_TESTCTRL_INTERNAL_FUNCTIONS      17  | 
7702  |  | #define SQLITE_TESTCTRL_LOCALTIME_FAULT         18  | 
7703  |  | #define SQLITE_TESTCTRL_EXPLAIN_STMT            19  /* NOT USED */  | 
7704  |  | #define SQLITE_TESTCTRL_ONCE_RESET_THRESHOLD    19  | 
7705  |  | #define SQLITE_TESTCTRL_NEVER_CORRUPT           20  | 
7706  |  | #define SQLITE_TESTCTRL_VDBE_COVERAGE           21  | 
7707  |  | #define SQLITE_TESTCTRL_BYTEORDER               22  | 
7708  |  | #define SQLITE_TESTCTRL_ISINIT                  23  | 
7709  |  | #define SQLITE_TESTCTRL_SORTER_MMAP             24  | 
7710  |  | #define SQLITE_TESTCTRL_IMPOSTER                25  | 
7711  |  | #define SQLITE_TESTCTRL_PARSER_COVERAGE         26  | 
7712  |  | #define SQLITE_TESTCTRL_RESULT_INTREAL          27  | 
7713  |  | #define SQLITE_TESTCTRL_PRNG_SEED               28  | 
7714  |  | #define SQLITE_TESTCTRL_EXTRA_SCHEMA_CHECKS     29  | 
7715  |  | #define SQLITE_TESTCTRL_LAST                    29  /* Largest TESTCTRL */  | 
7716  |  |  | 
7717  |  | /*  | 
7718  |  | ** CAPI3REF: SQL Keyword Checking  | 
7719  |  | **  | 
7720  |  | ** These routines provide access to the set of SQL language keywords  | 
7721  |  | ** recognized by SQLite.  Applications can uses these routines to determine  | 
7722  |  | ** whether or not a specific identifier needs to be escaped (for example,  | 
7723  |  | ** by enclosing in double-quotes) so as not to confuse the parser.  | 
7724  |  | **  | 
7725  |  | ** The sqlite3_keyword_count() interface returns the number of distinct  | 
7726  |  | ** keywords understood by SQLite.  | 
7727  |  | **  | 
7728  |  | ** The sqlite3_keyword_name(N,Z,L) interface finds the N-th keyword and  | 
7729  |  | ** makes *Z point to that keyword expressed as UTF8 and writes the number  | 
7730  |  | ** of bytes in the keyword into *L.  The string that *Z points to is not  | 
7731  |  | ** zero-terminated.  The sqlite3_keyword_name(N,Z,L) routine returns  | 
7732  |  | ** SQLITE_OK if N is within bounds and SQLITE_ERROR if not. If either Z  | 
7733  |  | ** or L are NULL or invalid pointers then calls to  | 
7734  |  | ** sqlite3_keyword_name(N,Z,L) result in undefined behavior.  | 
7735  |  | **  | 
7736  |  | ** The sqlite3_keyword_check(Z,L) interface checks to see whether or not  | 
7737  |  | ** the L-byte UTF8 identifier that Z points to is a keyword, returning non-zero  | 
7738  |  | ** if it is and zero if not.  | 
7739  |  | **  | 
7740  |  | ** The parser used by SQLite is forgiving.  It is often possible to use  | 
7741  |  | ** a keyword as an identifier as long as such use does not result in a  | 
7742  |  | ** parsing ambiguity.  For example, the statement  | 
7743  |  | ** "CREATE TABLE BEGIN(REPLACE,PRAGMA,END);" is accepted by SQLite, and  | 
7744  |  | ** creates a new table named "BEGIN" with three columns named  | 
7745  |  | ** "REPLACE", "PRAGMA", and "END".  Nevertheless, best practice is to avoid  | 
7746  |  | ** using keywords as identifiers.  Common techniques used to avoid keyword  | 
7747  |  | ** name collisions include:  | 
7748  |  | ** <ul>  | 
7749  |  | ** <li> Put all identifier names inside double-quotes.  This is the official  | 
7750  |  | **      SQL way to escape identifier names.  | 
7751  |  | ** <li> Put identifier names inside [...].  This is not standard SQL,  | 
7752  |  | **      but it is what SQL Server does and so lots of programmers use this  | 
7753  |  | **      technique.  | 
7754  |  | ** <li> Begin every identifier with the letter "Z" as no SQL keywords start  | 
7755  |  | **      with "Z".  | 
7756  |  | ** <li> Include a digit somewhere in every identifier name.  | 
7757  |  | ** </ul>  | 
7758  |  | **  | 
7759  |  | ** Note that the number of keywords understood by SQLite can depend on  | 
7760  |  | ** compile-time options.  For example, "VACUUM" is not a keyword if  | 
7761  |  | ** SQLite is compiled with the [-DSQLITE_OMIT_VACUUM] option.  Also,  | 
7762  |  | ** new keywords may be added to future releases of SQLite.  | 
7763  |  | */  | 
7764  |  | SQLITE_API int sqlite3_keyword_count(void);  | 
7765  |  | SQLITE_API int sqlite3_keyword_name(int,const char**,int*);  | 
7766  |  | SQLITE_API int sqlite3_keyword_check(const char*,int);  | 
7767  |  |  | 
7768  |  | /*  | 
7769  |  | ** CAPI3REF: Dynamic String Object  | 
7770  |  | ** KEYWORDS: {dynamic string} | 
7771  |  | **  | 
7772  |  | ** An instance of the sqlite3_str object contains a dynamically-sized  | 
7773  |  | ** string under construction.  | 
7774  |  | **  | 
7775  |  | ** The lifecycle of an sqlite3_str object is as follows:  | 
7776  |  | ** <ol>  | 
7777  |  | ** <li> ^The sqlite3_str object is created using [sqlite3_str_new()].  | 
7778  |  | ** <li> ^Text is appended to the sqlite3_str object using various  | 
7779  |  | ** methods, such as [sqlite3_str_appendf()].  | 
7780  |  | ** <li> ^The sqlite3_str object is destroyed and the string it created  | 
7781  |  | ** is returned using the [sqlite3_str_finish()] interface.  | 
7782  |  | ** </ol>  | 
7783  |  | */  | 
7784  |  | typedef struct sqlite3_str sqlite3_str;  | 
7785  |  |  | 
7786  |  | /*  | 
7787  |  | ** CAPI3REF: Create A New Dynamic String Object  | 
7788  |  | ** CONSTRUCTOR: sqlite3_str  | 
7789  |  | **  | 
7790  |  | ** ^The [sqlite3_str_new(D)] interface allocates and initializes  | 
7791  |  | ** a new [sqlite3_str] object.  To avoid memory leaks, the object returned by  | 
7792  |  | ** [sqlite3_str_new()] must be freed by a subsequent call to  | 
7793  |  | ** [sqlite3_str_finish(X)].  | 
7794  |  | **  | 
7795  |  | ** ^The [sqlite3_str_new(D)] interface always returns a pointer to a  | 
7796  |  | ** valid [sqlite3_str] object, though in the event of an out-of-memory  | 
7797  |  | ** error the returned object might be a special singleton that will  | 
7798  |  | ** silently reject new text, always return SQLITE_NOMEM from  | 
7799  |  | ** [sqlite3_str_errcode()], always return 0 for  | 
7800  |  | ** [sqlite3_str_length()], and always return NULL from  | 
7801  |  | ** [sqlite3_str_finish(X)].  It is always safe to use the value  | 
7802  |  | ** returned by [sqlite3_str_new(D)] as the sqlite3_str parameter  | 
7803  |  | ** to any of the other [sqlite3_str] methods.  | 
7804  |  | **  | 
7805  |  | ** The D parameter to [sqlite3_str_new(D)] may be NULL.  If the  | 
7806  |  | ** D parameter in [sqlite3_str_new(D)] is not NULL, then the maximum  | 
7807  |  | ** length of the string contained in the [sqlite3_str] object will be  | 
7808  |  | ** the value set for [sqlite3_limit](D,[SQLITE_LIMIT_LENGTH]) instead  | 
7809  |  | ** of [SQLITE_MAX_LENGTH].  | 
7810  |  | */  | 
7811  |  | SQLITE_API sqlite3_str *sqlite3_str_new(sqlite3*);  | 
7812  |  |  | 
7813  |  | /*  | 
7814  |  | ** CAPI3REF: Finalize A Dynamic String  | 
7815  |  | ** DESTRUCTOR: sqlite3_str  | 
7816  |  | **  | 
7817  |  | ** ^The [sqlite3_str_finish(X)] interface destroys the sqlite3_str object X  | 
7818  |  | ** and returns a pointer to a memory buffer obtained from [sqlite3_malloc64()]  | 
7819  |  | ** that contains the constructed string.  The calling application should  | 
7820  |  | ** pass the returned value to [sqlite3_free()] to avoid a memory leak.  | 
7821  |  | ** ^The [sqlite3_str_finish(X)] interface may return a NULL pointer if any  | 
7822  |  | ** errors were encountered during construction of the string.  ^The  | 
7823  |  | ** [sqlite3_str_finish(X)] interface will also return a NULL pointer if the  | 
7824  |  | ** string in [sqlite3_str] object X is zero bytes long.  | 
7825  |  | */  | 
7826  |  | SQLITE_API char *sqlite3_str_finish(sqlite3_str*);  | 
7827  |  |  | 
7828  |  | /*  | 
7829  |  | ** CAPI3REF: Add Content To A Dynamic String  | 
7830  |  | ** METHOD: sqlite3_str  | 
7831  |  | **  | 
7832  |  | ** These interfaces add content to an sqlite3_str object previously obtained  | 
7833  |  | ** from [sqlite3_str_new()].  | 
7834  |  | **  | 
7835  |  | ** ^The [sqlite3_str_appendf(X,F,...)] and  | 
7836  |  | ** [sqlite3_str_vappendf(X,F,V)] interfaces uses the [built-in printf]  | 
7837  |  | ** functionality of SQLite to append formatted text onto the end of  | 
7838  |  | ** [sqlite3_str] object X.  | 
7839  |  | **  | 
7840  |  | ** ^The [sqlite3_str_append(X,S,N)] method appends exactly N bytes from string S  | 
7841  |  | ** onto the end of the [sqlite3_str] object X.  N must be non-negative.  | 
7842  |  | ** S must contain at least N non-zero bytes of content.  To append a  | 
7843  |  | ** zero-terminated string in its entirety, use the [sqlite3_str_appendall()]  | 
7844  |  | ** method instead.  | 
7845  |  | **  | 
7846  |  | ** ^The [sqlite3_str_appendall(X,S)] method appends the complete content of  | 
7847  |  | ** zero-terminated string S onto the end of [sqlite3_str] object X.  | 
7848  |  | **  | 
7849  |  | ** ^The [sqlite3_str_appendchar(X,N,C)] method appends N copies of the  | 
7850  |  | ** single-byte character C onto the end of [sqlite3_str] object X.  | 
7851  |  | ** ^This method can be used, for example, to add whitespace indentation.  | 
7852  |  | **  | 
7853  |  | ** ^The [sqlite3_str_reset(X)] method resets the string under construction  | 
7854  |  | ** inside [sqlite3_str] object X back to zero bytes in length.  | 
7855  |  | **  | 
7856  |  | ** These methods do not return a result code.  ^If an error occurs, that fact  | 
7857  |  | ** is recorded in the [sqlite3_str] object and can be recovered by a  | 
7858  |  | ** subsequent call to [sqlite3_str_errcode(X)].  | 
7859  |  | */  | 
7860  |  | SQLITE_API void sqlite3_str_appendf(sqlite3_str*, const char *zFormat, ...);  | 
7861  |  | SQLITE_API void sqlite3_str_vappendf(sqlite3_str*, const char *zFormat, va_list);  | 
7862  |  | SQLITE_API void sqlite3_str_append(sqlite3_str*, const char *zIn, int N);  | 
7863  |  | SQLITE_API void sqlite3_str_appendall(sqlite3_str*, const char *zIn);  | 
7864  |  | SQLITE_API void sqlite3_str_appendchar(sqlite3_str*, int N, char C);  | 
7865  |  | SQLITE_API void sqlite3_str_reset(sqlite3_str*);  | 
7866  |  |  | 
7867  |  | /*  | 
7868  |  | ** CAPI3REF: Status Of A Dynamic String  | 
7869  |  | ** METHOD: sqlite3_str  | 
7870  |  | **  | 
7871  |  | ** These interfaces return the current status of an [sqlite3_str] object.  | 
7872  |  | **  | 
7873  |  | ** ^If any prior errors have occurred while constructing the dynamic string  | 
7874  |  | ** in sqlite3_str X, then the [sqlite3_str_errcode(X)] method will return  | 
7875  |  | ** an appropriate error code.  ^The [sqlite3_str_errcode(X)] method returns  | 
7876  |  | ** [SQLITE_NOMEM] following any out-of-memory error, or  | 
7877  |  | ** [SQLITE_TOOBIG] if the size of the dynamic string exceeds  | 
7878  |  | ** [SQLITE_MAX_LENGTH], or [SQLITE_OK] if there have been no errors.  | 
7879  |  | **  | 
7880  |  | ** ^The [sqlite3_str_length(X)] method returns the current length, in bytes,  | 
7881  |  | ** of the dynamic string under construction in [sqlite3_str] object X.  | 
7882  |  | ** ^The length returned by [sqlite3_str_length(X)] does not include the  | 
7883  |  | ** zero-termination byte.  | 
7884  |  | **  | 
7885  |  | ** ^The [sqlite3_str_value(X)] method returns a pointer to the current  | 
7886  |  | ** content of the dynamic string under construction in X.  The value  | 
7887  |  | ** returned by [sqlite3_str_value(X)] is managed by the sqlite3_str object X  | 
7888  |  | ** and might be freed or altered by any subsequent method on the same  | 
7889  |  | ** [sqlite3_str] object.  Applications must not used the pointer returned  | 
7890  |  | ** [sqlite3_str_value(X)] after any subsequent method call on the same  | 
7891  |  | ** object.  ^Applications may change the content of the string returned  | 
7892  |  | ** by [sqlite3_str_value(X)] as long as they do not write into any bytes  | 
7893  |  | ** outside the range of 0 to [sqlite3_str_length(X)] and do not read or  | 
7894  |  | ** write any byte after any subsequent sqlite3_str method call.  | 
7895  |  | */  | 
7896  |  | SQLITE_API int sqlite3_str_errcode(sqlite3_str*);  | 
7897  |  | SQLITE_API int sqlite3_str_length(sqlite3_str*);  | 
7898  |  | SQLITE_API char *sqlite3_str_value(sqlite3_str*);  | 
7899  |  |  | 
7900  |  | /*  | 
7901  |  | ** CAPI3REF: SQLite Runtime Status  | 
7902  |  | **  | 
7903  |  | ** ^These interfaces are used to retrieve runtime status information  | 
7904  |  | ** about the performance of SQLite, and optionally to reset various  | 
7905  |  | ** highwater marks.  ^The first argument is an integer code for  | 
7906  |  | ** the specific parameter to measure.  ^(Recognized integer codes  | 
7907  |  | ** are of the form [status parameters | SQLITE_STATUS_...].)^  | 
7908  |  | ** ^The current value of the parameter is returned into *pCurrent.  | 
7909  |  | ** ^The highest recorded value is returned in *pHighwater.  ^If the  | 
7910  |  | ** resetFlag is true, then the highest record value is reset after  | 
7911  |  | ** *pHighwater is written.  ^(Some parameters do not record the highest  | 
7912  |  | ** value.  For those parameters  | 
7913  |  | ** nothing is written into *pHighwater and the resetFlag is ignored.)^  | 
7914  |  | ** ^(Other parameters record only the highwater mark and not the current  | 
7915  |  | ** value.  For these latter parameters nothing is written into *pCurrent.)^  | 
7916  |  | **  | 
7917  |  | ** ^The sqlite3_status() and sqlite3_status64() routines return  | 
7918  |  | ** SQLITE_OK on success and a non-zero [error code] on failure.  | 
7919  |  | **  | 
7920  |  | ** If either the current value or the highwater mark is too large to  | 
7921  |  | ** be represented by a 32-bit integer, then the values returned by  | 
7922  |  | ** sqlite3_status() are undefined.  | 
7923  |  | **  | 
7924  |  | ** See also: [sqlite3_db_status()]  | 
7925  |  | */  | 
7926  |  | SQLITE_API int sqlite3_status(int op, int *pCurrent, int *pHighwater, int resetFlag);  | 
7927  |  | SQLITE_API int sqlite3_status64(  | 
7928  |  |   int op,  | 
7929  |  |   sqlite3_int64 *pCurrent,  | 
7930  |  |   sqlite3_int64 *pHighwater,  | 
7931  |  |   int resetFlag  | 
7932  |  | );  | 
7933  |  |  | 
7934  |  |  | 
7935  |  | /*  | 
7936  |  | ** CAPI3REF: Status Parameters  | 
7937  |  | ** KEYWORDS: {status parameters} | 
7938  |  | **  | 
7939  |  | ** These integer constants designate various run-time status parameters  | 
7940  |  | ** that can be returned by [sqlite3_status()].  | 
7941  |  | **  | 
7942  |  | ** <dl>  | 
7943  |  | ** [[SQLITE_STATUS_MEMORY_USED]] ^(<dt>SQLITE_STATUS_MEMORY_USED</dt>  | 
7944  |  | ** <dd>This parameter is the current amount of memory checked out  | 
7945  |  | ** using [sqlite3_malloc()], either directly or indirectly.  The  | 
7946  |  | ** figure includes calls made to [sqlite3_malloc()] by the application  | 
7947  |  | ** and internal memory usage by the SQLite library.  Auxiliary page-cache  | 
7948  |  | ** memory controlled by [SQLITE_CONFIG_PAGECACHE] is not included in  | 
7949  |  | ** this parameter.  The amount returned is the sum of the allocation  | 
7950  |  | ** sizes as reported by the xSize method in [sqlite3_mem_methods].</dd>)^  | 
7951  |  | **  | 
7952  |  | ** [[SQLITE_STATUS_MALLOC_SIZE]] ^(<dt>SQLITE_STATUS_MALLOC_SIZE</dt>  | 
7953  |  | ** <dd>This parameter records the largest memory allocation request  | 
7954  |  | ** handed to [sqlite3_malloc()] or [sqlite3_realloc()] (or their  | 
7955  |  | ** internal equivalents).  Only the value returned in the  | 
7956  |  | ** *pHighwater parameter to [sqlite3_status()] is of interest.  | 
7957  |  | ** The value written into the *pCurrent parameter is undefined.</dd>)^  | 
7958  |  | **  | 
7959  |  | ** [[SQLITE_STATUS_MALLOC_COUNT]] ^(<dt>SQLITE_STATUS_MALLOC_COUNT</dt>  | 
7960  |  | ** <dd>This parameter records the number of separate memory allocations  | 
7961  |  | ** currently checked out.</dd>)^  | 
7962  |  | **  | 
7963  |  | ** [[SQLITE_STATUS_PAGECACHE_USED]] ^(<dt>SQLITE_STATUS_PAGECACHE_USED</dt>  | 
7964  |  | ** <dd>This parameter returns the number of pages used out of the  | 
7965  |  | ** [pagecache memory allocator] that was configured using  | 
7966  |  | ** [SQLITE_CONFIG_PAGECACHE].  The  | 
7967  |  | ** value returned is in pages, not in bytes.</dd>)^  | 
7968  |  | **  | 
7969  |  | ** [[SQLITE_STATUS_PAGECACHE_OVERFLOW]]  | 
7970  |  | ** ^(<dt>SQLITE_STATUS_PAGECACHE_OVERFLOW</dt>  | 
7971  |  | ** <dd>This parameter returns the number of bytes of page cache  | 
7972  |  | ** allocation which could not be satisfied by the [SQLITE_CONFIG_PAGECACHE]  | 
7973  |  | ** buffer and where forced to overflow to [sqlite3_malloc()].  The  | 
7974  |  | ** returned value includes allocations that overflowed because they  | 
7975  |  | ** where too large (they were larger than the "sz" parameter to  | 
7976  |  | ** [SQLITE_CONFIG_PAGECACHE]) and allocations that overflowed because  | 
7977  |  | ** no space was left in the page cache.</dd>)^  | 
7978  |  | **  | 
7979  |  | ** [[SQLITE_STATUS_PAGECACHE_SIZE]] ^(<dt>SQLITE_STATUS_PAGECACHE_SIZE</dt>  | 
7980  |  | ** <dd>This parameter records the largest memory allocation request  | 
7981  |  | ** handed to the [pagecache memory allocator].  Only the value returned in the  | 
7982  |  | ** *pHighwater parameter to [sqlite3_status()] is of interest.  | 
7983  |  | ** The value written into the *pCurrent parameter is undefined.</dd>)^  | 
7984  |  | **  | 
7985  |  | ** [[SQLITE_STATUS_SCRATCH_USED]] <dt>SQLITE_STATUS_SCRATCH_USED</dt>  | 
7986  |  | ** <dd>No longer used.</dd>  | 
7987  |  | **  | 
7988  |  | ** [[SQLITE_STATUS_SCRATCH_OVERFLOW]] ^(<dt>SQLITE_STATUS_SCRATCH_OVERFLOW</dt>  | 
7989  |  | ** <dd>No longer used.</dd>  | 
7990  |  | **  | 
7991  |  | ** [[SQLITE_STATUS_SCRATCH_SIZE]] <dt>SQLITE_STATUS_SCRATCH_SIZE</dt>  | 
7992  |  | ** <dd>No longer used.</dd>  | 
7993  |  | **  | 
7994  |  | ** [[SQLITE_STATUS_PARSER_STACK]] ^(<dt>SQLITE_STATUS_PARSER_STACK</dt>  | 
7995  |  | ** <dd>The *pHighwater parameter records the deepest parser stack.  | 
7996  |  | ** The *pCurrent value is undefined.  The *pHighwater value is only  | 
7997  |  | ** meaningful if SQLite is compiled with [YYTRACKMAXSTACKDEPTH].</dd>)^  | 
7998  |  | ** </dl>  | 
7999  |  | **  | 
8000  |  | ** New status parameters may be added from time to time.  | 
8001  |  | */  | 
8002  |  | #define SQLITE_STATUS_MEMORY_USED          0  | 
8003  |  | #define SQLITE_STATUS_PAGECACHE_USED       1  | 
8004  |  | #define SQLITE_STATUS_PAGECACHE_OVERFLOW   2  | 
8005  |  | #define SQLITE_STATUS_SCRATCH_USED         3  /* NOT USED */  | 
8006  |  | #define SQLITE_STATUS_SCRATCH_OVERFLOW     4  /* NOT USED */  | 
8007  |  | #define SQLITE_STATUS_MALLOC_SIZE          5  | 
8008  |  | #define SQLITE_STATUS_PARSER_STACK         6  | 
8009  |  | #define SQLITE_STATUS_PAGECACHE_SIZE       7  | 
8010  |  | #define SQLITE_STATUS_SCRATCH_SIZE         8  /* NOT USED */  | 
8011  |  | #define SQLITE_STATUS_MALLOC_COUNT         9  | 
8012  |  |  | 
8013  |  | /*  | 
8014  |  | ** CAPI3REF: Database Connection Status  | 
8015  |  | ** METHOD: sqlite3  | 
8016  |  | **  | 
8017  |  | ** ^This interface is used to retrieve runtime status information  | 
8018  |  | ** about a single [database connection].  ^The first argument is the  | 
8019  |  | ** database connection object to be interrogated.  ^The second argument  | 
8020  |  | ** is an integer constant, taken from the set of  | 
8021  |  | ** [SQLITE_DBSTATUS options], that  | 
8022  |  | ** determines the parameter to interrogate.  The set of  | 
8023  |  | ** [SQLITE_DBSTATUS options] is likely  | 
8024  |  | ** to grow in future releases of SQLite.  | 
8025  |  | **  | 
8026  |  | ** ^The current value of the requested parameter is written into *pCur  | 
8027  |  | ** and the highest instantaneous value is written into *pHiwtr.  ^If  | 
8028  |  | ** the resetFlg is true, then the highest instantaneous value is  | 
8029  |  | ** reset back down to the current value.  | 
8030  |  | **  | 
8031  |  | ** ^The sqlite3_db_status() routine returns SQLITE_OK on success and a  | 
8032  |  | ** non-zero [error code] on failure.  | 
8033  |  | **  | 
8034  |  | ** See also: [sqlite3_status()] and [sqlite3_stmt_status()].  | 
8035  |  | */  | 
8036  |  | SQLITE_API int sqlite3_db_status(sqlite3*, int op, int *pCur, int *pHiwtr, int resetFlg);  | 
8037  |  |  | 
8038  |  | /*  | 
8039  |  | ** CAPI3REF: Status Parameters for database connections  | 
8040  |  | ** KEYWORDS: {SQLITE_DBSTATUS options} | 
8041  |  | **  | 
8042  |  | ** These constants are the available integer "verbs" that can be passed as  | 
8043  |  | ** the second argument to the [sqlite3_db_status()] interface.  | 
8044  |  | **  | 
8045  |  | ** New verbs may be added in future releases of SQLite. Existing verbs  | 
8046  |  | ** might be discontinued. Applications should check the return code from  | 
8047  |  | ** [sqlite3_db_status()] to make sure that the call worked.  | 
8048  |  | ** The [sqlite3_db_status()] interface will return a non-zero error code  | 
8049  |  | ** if a discontinued or unsupported verb is invoked.  | 
8050  |  | **  | 
8051  |  | ** <dl>  | 
8052  |  | ** [[SQLITE_DBSTATUS_LOOKASIDE_USED]] ^(<dt>SQLITE_DBSTATUS_LOOKASIDE_USED</dt>  | 
8053  |  | ** <dd>This parameter returns the number of lookaside memory slots currently  | 
8054  |  | ** checked out.</dd>)^  | 
8055  |  | **  | 
8056  |  | ** [[SQLITE_DBSTATUS_LOOKASIDE_HIT]] ^(<dt>SQLITE_DBSTATUS_LOOKASIDE_HIT</dt>  | 
8057  |  | ** <dd>This parameter returns the number of malloc attempts that were  | 
8058  |  | ** satisfied using lookaside memory. Only the high-water value is meaningful;  | 
8059  |  | ** the current value is always zero.)^  | 
8060  |  | **  | 
8061  |  | ** [[SQLITE_DBSTATUS_LOOKASIDE_MISS_SIZE]]  | 
8062  |  | ** ^(<dt>SQLITE_DBSTATUS_LOOKASIDE_MISS_SIZE</dt>  | 
8063  |  | ** <dd>This parameter returns the number malloc attempts that might have  | 
8064  |  | ** been satisfied using lookaside memory but failed due to the amount of  | 
8065  |  | ** memory requested being larger than the lookaside slot size.  | 
8066  |  | ** Only the high-water value is meaningful;  | 
8067  |  | ** the current value is always zero.)^  | 
8068  |  | **  | 
8069  |  | ** [[SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL]]  | 
8070  |  | ** ^(<dt>SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL</dt>  | 
8071  |  | ** <dd>This parameter returns the number malloc attempts that might have  | 
8072  |  | ** been satisfied using lookaside memory but failed due to all lookaside  | 
8073  |  | ** memory already being in use.  | 
8074  |  | ** Only the high-water value is meaningful;  | 
8075  |  | ** the current value is always zero.)^  | 
8076  |  | **  | 
8077  |  | ** [[SQLITE_DBSTATUS_CACHE_USED]] ^(<dt>SQLITE_DBSTATUS_CACHE_USED</dt>  | 
8078  |  | ** <dd>This parameter returns the approximate number of bytes of heap  | 
8079  |  | ** memory used by all pager caches associated with the database connection.)^  | 
8080  |  | ** ^The highwater mark associated with SQLITE_DBSTATUS_CACHE_USED is always 0.  | 
8081  |  | **  | 
8082  |  | ** [[SQLITE_DBSTATUS_CACHE_USED_SHARED]]  | 
8083  |  | ** ^(<dt>SQLITE_DBSTATUS_CACHE_USED_SHARED</dt>  | 
8084  |  | ** <dd>This parameter is similar to DBSTATUS_CACHE_USED, except that if a  | 
8085  |  | ** pager cache is shared between two or more connections the bytes of heap  | 
8086  |  | ** memory used by that pager cache is divided evenly between the attached  | 
8087  |  | ** connections.)^  In other words, if none of the pager caches associated  | 
8088  |  | ** with the database connection are shared, this request returns the same  | 
8089  |  | ** value as DBSTATUS_CACHE_USED. Or, if one or more or the pager caches are  | 
8090  |  | ** shared, the value returned by this call will be smaller than that returned  | 
8091  |  | ** by DBSTATUS_CACHE_USED. ^The highwater mark associated with  | 
8092  |  | ** SQLITE_DBSTATUS_CACHE_USED_SHARED is always 0.  | 
8093  |  | **  | 
8094  |  | ** [[SQLITE_DBSTATUS_SCHEMA_USED]] ^(<dt>SQLITE_DBSTATUS_SCHEMA_USED</dt>  | 
8095  |  | ** <dd>This parameter returns the approximate number of bytes of heap  | 
8096  |  | ** memory used to store the schema for all databases associated  | 
8097  |  | ** with the connection - main, temp, and any [ATTACH]-ed databases.)^  | 
8098  |  | ** ^The full amount of memory used by the schemas is reported, even if the  | 
8099  |  | ** schema memory is shared with other database connections due to  | 
8100  |  | ** [shared cache mode] being enabled.  | 
8101  |  | ** ^The highwater mark associated with SQLITE_DBSTATUS_SCHEMA_USED is always 0.  | 
8102  |  | **  | 
8103  |  | ** [[SQLITE_DBSTATUS_STMT_USED]] ^(<dt>SQLITE_DBSTATUS_STMT_USED</dt>  | 
8104  |  | ** <dd>This parameter returns the approximate number of bytes of heap  | 
8105  |  | ** and lookaside memory used by all prepared statements associated with  | 
8106  |  | ** the database connection.)^  | 
8107  |  | ** ^The highwater mark associated with SQLITE_DBSTATUS_STMT_USED is always 0.  | 
8108  |  | ** </dd>  | 
8109  |  | **  | 
8110  |  | ** [[SQLITE_DBSTATUS_CACHE_HIT]] ^(<dt>SQLITE_DBSTATUS_CACHE_HIT</dt>  | 
8111  |  | ** <dd>This parameter returns the number of pager cache hits that have  | 
8112  |  | ** occurred.)^ ^The highwater mark associated with SQLITE_DBSTATUS_CACHE_HIT  | 
8113  |  | ** is always 0.  | 
8114  |  | ** </dd>  | 
8115  |  | **  | 
8116  |  | ** [[SQLITE_DBSTATUS_CACHE_MISS]] ^(<dt>SQLITE_DBSTATUS_CACHE_MISS</dt>  | 
8117  |  | ** <dd>This parameter returns the number of pager cache misses that have  | 
8118  |  | ** occurred.)^ ^The highwater mark associated with SQLITE_DBSTATUS_CACHE_MISS  | 
8119  |  | ** is always 0.  | 
8120  |  | ** </dd>  | 
8121  |  | **  | 
8122  |  | ** [[SQLITE_DBSTATUS_CACHE_WRITE]] ^(<dt>SQLITE_DBSTATUS_CACHE_WRITE</dt>  | 
8123  |  | ** <dd>This parameter returns the number of dirty cache entries that have  | 
8124  |  | ** been written to disk. Specifically, the number of pages written to the  | 
8125  |  | ** wal file in wal mode databases, or the number of pages written to the  | 
8126  |  | ** database file in rollback mode databases. Any pages written as part of  | 
8127  |  | ** transaction rollback or database recovery operations are not included.  | 
8128  |  | ** If an IO or other error occurs while writing a page to disk, the effect  | 
8129  |  | ** on subsequent SQLITE_DBSTATUS_CACHE_WRITE requests is undefined.)^ ^The  | 
8130  |  | ** highwater mark associated with SQLITE_DBSTATUS_CACHE_WRITE is always 0.  | 
8131  |  | ** </dd>  | 
8132  |  | **  | 
8133  |  | ** [[SQLITE_DBSTATUS_CACHE_SPILL]] ^(<dt>SQLITE_DBSTATUS_CACHE_SPILL</dt>  | 
8134  |  | ** <dd>This parameter returns the number of dirty cache entries that have  | 
8135  |  | ** been written to disk in the middle of a transaction due to the page  | 
8136  |  | ** cache overflowing. Transactions are more efficient if they are written  | 
8137  |  | ** to disk all at once. When pages spill mid-transaction, that introduces  | 
8138  |  | ** additional overhead. This parameter can be used help identify  | 
8139  |  | ** inefficiencies that can be resolved by increasing the cache size.  | 
8140  |  | ** </dd>  | 
8141  |  | **  | 
8142  |  | ** [[SQLITE_DBSTATUS_DEFERRED_FKS]] ^(<dt>SQLITE_DBSTATUS_DEFERRED_FKS</dt>  | 
8143  |  | ** <dd>This parameter returns zero for the current value if and only if  | 
8144  |  | ** all foreign key constraints (deferred or immediate) have been  | 
8145  |  | ** resolved.)^  ^The highwater mark is always 0.  | 
8146  |  | ** </dd>  | 
8147  |  | ** </dl>  | 
8148  |  | */  | 
8149  |  | #define SQLITE_DBSTATUS_LOOKASIDE_USED       0  | 
8150  |  | #define SQLITE_DBSTATUS_CACHE_USED           1  | 
8151  |  | #define SQLITE_DBSTATUS_SCHEMA_USED          2  | 
8152  |  | #define SQLITE_DBSTATUS_STMT_USED            3  | 
8153  |  | #define SQLITE_DBSTATUS_LOOKASIDE_HIT        4  | 
8154  |  | #define SQLITE_DBSTATUS_LOOKASIDE_MISS_SIZE  5  | 
8155  |  | #define SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL  6  | 
8156  |  | #define SQLITE_DBSTATUS_CACHE_HIT            7  | 
8157  |  | #define SQLITE_DBSTATUS_CACHE_MISS           8  | 
8158  |  | #define SQLITE_DBSTATUS_CACHE_WRITE          9  | 
8159  |  | #define SQLITE_DBSTATUS_DEFERRED_FKS        10  | 
8160  |  | #define SQLITE_DBSTATUS_CACHE_USED_SHARED   11  | 
8161  |  | #define SQLITE_DBSTATUS_CACHE_SPILL         12  | 
8162  |  | #define SQLITE_DBSTATUS_MAX                 12   /* Largest defined DBSTATUS */  | 
8163  |  |  | 
8164  |  |  | 
8165  |  | /*  | 
8166  |  | ** CAPI3REF: Prepared Statement Status  | 
8167  |  | ** METHOD: sqlite3_stmt  | 
8168  |  | **  | 
8169  |  | ** ^(Each prepared statement maintains various  | 
8170  |  | ** [SQLITE_STMTSTATUS counters] that measure the number  | 
8171  |  | ** of times it has performed specific operations.)^  These counters can  | 
8172  |  | ** be used to monitor the performance characteristics of the prepared  | 
8173  |  | ** statements.  For example, if the number of table steps greatly exceeds  | 
8174  |  | ** the number of table searches or result rows, that would tend to indicate  | 
8175  |  | ** that the prepared statement is using a full table scan rather than  | 
8176  |  | ** an index.  | 
8177  |  | **  | 
8178  |  | ** ^(This interface is used to retrieve and reset counter values from  | 
8179  |  | ** a [prepared statement].  The first argument is the prepared statement  | 
8180  |  | ** object to be interrogated.  The second argument  | 
8181  |  | ** is an integer code for a specific [SQLITE_STMTSTATUS counter]  | 
8182  |  | ** to be interrogated.)^  | 
8183  |  | ** ^The current value of the requested counter is returned.  | 
8184  |  | ** ^If the resetFlg is true, then the counter is reset to zero after this  | 
8185  |  | ** interface call returns.  | 
8186  |  | **  | 
8187  |  | ** See also: [sqlite3_status()] and [sqlite3_db_status()].  | 
8188  |  | */  | 
8189  |  | SQLITE_API int sqlite3_stmt_status(sqlite3_stmt*, int op,int resetFlg);  | 
8190  |  |  | 
8191  |  | /*  | 
8192  |  | ** CAPI3REF: Status Parameters for prepared statements  | 
8193  |  | ** KEYWORDS: {SQLITE_STMTSTATUS counter} {SQLITE_STMTSTATUS counters} | 
8194  |  | **  | 
8195  |  | ** These preprocessor macros define integer codes that name counter  | 
8196  |  | ** values associated with the [sqlite3_stmt_status()] interface.  | 
8197  |  | ** The meanings of the various counters are as follows:  | 
8198  |  | **  | 
8199  |  | ** <dl>  | 
8200  |  | ** [[SQLITE_STMTSTATUS_FULLSCAN_STEP]] <dt>SQLITE_STMTSTATUS_FULLSCAN_STEP</dt>  | 
8201  |  | ** <dd>^This is the number of times that SQLite has stepped forward in  | 
8202  |  | ** a table as part of a full table scan.  Large numbers for this counter  | 
8203  |  | ** may indicate opportunities for performance improvement through  | 
8204  |  | ** careful use of indices.</dd>  | 
8205  |  | **  | 
8206  |  | ** [[SQLITE_STMTSTATUS_SORT]] <dt>SQLITE_STMTSTATUS_SORT</dt>  | 
8207  |  | ** <dd>^This is the number of sort operations that have occurred.  | 
8208  |  | ** A non-zero value in this counter may indicate an opportunity to  | 
8209  |  | ** improvement performance through careful use of indices.</dd>  | 
8210  |  | **  | 
8211  |  | ** [[SQLITE_STMTSTATUS_AUTOINDEX]] <dt>SQLITE_STMTSTATUS_AUTOINDEX</dt>  | 
8212  |  | ** <dd>^This is the number of rows inserted into transient indices that  | 
8213  |  | ** were created automatically in order to help joins run faster.  | 
8214  |  | ** A non-zero value in this counter may indicate an opportunity to  | 
8215  |  | ** improvement performance by adding permanent indices that do not  | 
8216  |  | ** need to be reinitialized each time the statement is run.</dd>  | 
8217  |  | **  | 
8218  |  | ** [[SQLITE_STMTSTATUS_VM_STEP]] <dt>SQLITE_STMTSTATUS_VM_STEP</dt>  | 
8219  |  | ** <dd>^This is the number of virtual machine operations executed  | 
8220  |  | ** by the prepared statement if that number is less than or equal  | 
8221  |  | ** to 2147483647.  The number of virtual machine operations can be  | 
8222  |  | ** used as a proxy for the total work done by the prepared statement.  | 
8223  |  | ** If the number of virtual machine operations exceeds 2147483647  | 
8224  |  | ** then the value returned by this statement status code is undefined.  | 
8225  |  | **  | 
8226  |  | ** [[SQLITE_STMTSTATUS_REPREPARE]] <dt>SQLITE_STMTSTATUS_REPREPARE</dt>  | 
8227  |  | ** <dd>^This is the number of times that the prepare statement has been  | 
8228  |  | ** automatically regenerated due to schema changes or changes to  | 
8229  |  | ** [bound parameters] that might affect the query plan.  | 
8230  |  | **  | 
8231  |  | ** [[SQLITE_STMTSTATUS_RUN]] <dt>SQLITE_STMTSTATUS_RUN</dt>  | 
8232  |  | ** <dd>^This is the number of times that the prepared statement has  | 
8233  |  | ** been run.  A single "run" for the purposes of this counter is one  | 
8234  |  | ** or more calls to [sqlite3_step()] followed by a call to [sqlite3_reset()].  | 
8235  |  | ** The counter is incremented on the first [sqlite3_step()] call of each  | 
8236  |  | ** cycle.  | 
8237  |  | **  | 
8238  |  | ** [[SQLITE_STMTSTATUS_MEMUSED]] <dt>SQLITE_STMTSTATUS_MEMUSED</dt>  | 
8239  |  | ** <dd>^This is the approximate number of bytes of heap memory  | 
8240  |  | ** used to store the prepared statement.  ^This value is not actually  | 
8241  |  | ** a counter, and so the resetFlg parameter to sqlite3_stmt_status()  | 
8242  |  | ** is ignored when the opcode is SQLITE_STMTSTATUS_MEMUSED.  | 
8243  |  | ** </dd>  | 
8244  |  | ** </dl>  | 
8245  |  | */  | 
8246  |  | #define SQLITE_STMTSTATUS_FULLSCAN_STEP     1  | 
8247  |  | #define SQLITE_STMTSTATUS_SORT              2  | 
8248  |  | #define SQLITE_STMTSTATUS_AUTOINDEX         3  | 
8249  |  | #define SQLITE_STMTSTATUS_VM_STEP           4  | 
8250  |  | #define SQLITE_STMTSTATUS_REPREPARE         5  | 
8251  |  | #define SQLITE_STMTSTATUS_RUN               6  | 
8252  |  | #define SQLITE_STMTSTATUS_MEMUSED           99  | 
8253  |  |  | 
8254  |  | /*  | 
8255  |  | ** CAPI3REF: Custom Page Cache Object  | 
8256  |  | **  | 
8257  |  | ** The sqlite3_pcache type is opaque.  It is implemented by  | 
8258  |  | ** the pluggable module.  The SQLite core has no knowledge of  | 
8259  |  | ** its size or internal structure and never deals with the  | 
8260  |  | ** sqlite3_pcache object except by holding and passing pointers  | 
8261  |  | ** to the object.  | 
8262  |  | **  | 
8263  |  | ** See [sqlite3_pcache_methods2] for additional information.  | 
8264  |  | */  | 
8265  |  | typedef struct sqlite3_pcache sqlite3_pcache;  | 
8266  |  |  | 
8267  |  | /*  | 
8268  |  | ** CAPI3REF: Custom Page Cache Object  | 
8269  |  | **  | 
8270  |  | ** The sqlite3_pcache_page object represents a single page in the  | 
8271  |  | ** page cache.  The page cache will allocate instances of this  | 
8272  |  | ** object.  Various methods of the page cache use pointers to instances  | 
8273  |  | ** of this object as parameters or as their return value.  | 
8274  |  | **  | 
8275  |  | ** See [sqlite3_pcache_methods2] for additional information.  | 
8276  |  | */  | 
8277  |  | typedef struct sqlite3_pcache_page sqlite3_pcache_page;  | 
8278  |  | struct sqlite3_pcache_page { | 
8279  |  |   void *pBuf;        /* The content of the page */  | 
8280  |  |   void *pExtra;      /* Extra information associated with the page */  | 
8281  |  | };  | 
8282  |  |  | 
8283  |  | /*  | 
8284  |  | ** CAPI3REF: Application Defined Page Cache.  | 
8285  |  | ** KEYWORDS: {page cache} | 
8286  |  | **  | 
8287  |  | ** ^(The [sqlite3_config]([SQLITE_CONFIG_PCACHE2], ...) interface can  | 
8288  |  | ** register an alternative page cache implementation by passing in an  | 
8289  |  | ** instance of the sqlite3_pcache_methods2 structure.)^  | 
8290  |  | ** In many applications, most of the heap memory allocated by  | 
8291  |  | ** SQLite is used for the page cache.  | 
8292  |  | ** By implementing a  | 
8293  |  | ** custom page cache using this API, an application can better control  | 
8294  |  | ** the amount of memory consumed by SQLite, the way in which  | 
8295  |  | ** that memory is allocated and released, and the policies used to  | 
8296  |  | ** determine exactly which parts of a database file are cached and for  | 
8297  |  | ** how long.  | 
8298  |  | **  | 
8299  |  | ** The alternative page cache mechanism is an  | 
8300  |  | ** extreme measure that is only needed by the most demanding applications.  | 
8301  |  | ** The built-in page cache is recommended for most uses.  | 
8302  |  | **  | 
8303  |  | ** ^(The contents of the sqlite3_pcache_methods2 structure are copied to an  | 
8304  |  | ** internal buffer by SQLite within the call to [sqlite3_config].  Hence  | 
8305  |  | ** the application may discard the parameter after the call to  | 
8306  |  | ** [sqlite3_config()] returns.)^  | 
8307  |  | **  | 
8308  |  | ** [[the xInit() page cache method]]  | 
8309  |  | ** ^(The xInit() method is called once for each effective  | 
8310  |  | ** call to [sqlite3_initialize()])^  | 
8311  |  | ** (usually only once during the lifetime of the process). ^(The xInit()  | 
8312  |  | ** method is passed a copy of the sqlite3_pcache_methods2.pArg value.)^  | 
8313  |  | ** The intent of the xInit() method is to set up global data structures  | 
8314  |  | ** required by the custom page cache implementation.  | 
8315  |  | ** ^(If the xInit() method is NULL, then the  | 
8316  |  | ** built-in default page cache is used instead of the application defined  | 
8317  |  | ** page cache.)^  | 
8318  |  | **  | 
8319  |  | ** [[the xShutdown() page cache method]]  | 
8320  |  | ** ^The xShutdown() method is called by [sqlite3_shutdown()].  | 
8321  |  | ** It can be used to clean up  | 
8322  |  | ** any outstanding resources before process shutdown, if required.  | 
8323  |  | ** ^The xShutdown() method may be NULL.  | 
8324  |  | **  | 
8325  |  | ** ^SQLite automatically serializes calls to the xInit method,  | 
8326  |  | ** so the xInit method need not be threadsafe.  ^The  | 
8327  |  | ** xShutdown method is only called from [sqlite3_shutdown()] so it does  | 
8328  |  | ** not need to be threadsafe either.  All other methods must be threadsafe  | 
8329  |  | ** in multithreaded applications.  | 
8330  |  | **  | 
8331  |  | ** ^SQLite will never invoke xInit() more than once without an intervening  | 
8332  |  | ** call to xShutdown().  | 
8333  |  | **  | 
8334  |  | ** [[the xCreate() page cache methods]]  | 
8335  |  | ** ^SQLite invokes the xCreate() method to construct a new cache instance.  | 
8336  |  | ** SQLite will typically create one cache instance for each open database file,  | 
8337  |  | ** though this is not guaranteed. ^The  | 
8338  |  | ** first parameter, szPage, is the size in bytes of the pages that must  | 
8339  |  | ** be allocated by the cache.  ^szPage will always a power of two.  ^The  | 
8340  |  | ** second parameter szExtra is a number of bytes of extra storage  | 
8341  |  | ** associated with each page cache entry.  ^The szExtra parameter will  | 
8342  |  | ** a number less than 250.  SQLite will use the  | 
8343  |  | ** extra szExtra bytes on each page to store metadata about the underlying  | 
8344  |  | ** database page on disk.  The value passed into szExtra depends  | 
8345  |  | ** on the SQLite version, the target platform, and how SQLite was compiled.  | 
8346  |  | ** ^The third argument to xCreate(), bPurgeable, is true if the cache being  | 
8347  |  | ** created will be used to cache database pages of a file stored on disk, or  | 
8348  |  | ** false if it is used for an in-memory database. The cache implementation  | 
8349  |  | ** does not have to do anything special based with the value of bPurgeable;  | 
8350  |  | ** it is purely advisory.  ^On a cache where bPurgeable is false, SQLite will  | 
8351  |  | ** never invoke xUnpin() except to deliberately delete a page.  | 
8352  |  | ** ^In other words, calls to xUnpin() on a cache with bPurgeable set to  | 
8353  |  | ** false will always have the "discard" flag set to true.  | 
8354  |  | ** ^Hence, a cache created with bPurgeable false will  | 
8355  |  | ** never contain any unpinned pages.  | 
8356  |  | **  | 
8357  |  | ** [[the xCachesize() page cache method]]  | 
8358  |  | ** ^(The xCachesize() method may be called at any time by SQLite to set the  | 
8359  |  | ** suggested maximum cache-size (number of pages stored by) the cache  | 
8360  |  | ** instance passed as the first argument. This is the value configured using  | 
8361  |  | ** the SQLite "[PRAGMA cache_size]" command.)^  As with the bPurgeable  | 
8362  |  | ** parameter, the implementation is not required to do anything with this  | 
8363  |  | ** value; it is advisory only.  | 
8364  |  | **  | 
8365  |  | ** [[the xPagecount() page cache methods]]  | 
8366  |  | ** The xPagecount() method must return the number of pages currently  | 
8367  |  | ** stored in the cache, both pinned and unpinned.  | 
8368  |  | **  | 
8369  |  | ** [[the xFetch() page cache methods]]  | 
8370  |  | ** The xFetch() method locates a page in the cache and returns a pointer to  | 
8371  |  | ** an sqlite3_pcache_page object associated with that page, or a NULL pointer.  | 
8372  |  | ** The pBuf element of the returned sqlite3_pcache_page object will be a  | 
8373  |  | ** pointer to a buffer of szPage bytes used to store the content of a  | 
8374  |  | ** single database page.  The pExtra element of sqlite3_pcache_page will be  | 
8375  |  | ** a pointer to the szExtra bytes of extra storage that SQLite has requested  | 
8376  |  | ** for each entry in the page cache.  | 
8377  |  | **  | 
8378  |  | ** The page to be fetched is determined by the key. ^The minimum key value  | 
8379  |  | ** is 1.  After it has been retrieved using xFetch, the page is considered  | 
8380  |  | ** to be "pinned".  | 
8381  |  | **  | 
8382  |  | ** If the requested page is already in the page cache, then the page cache  | 
8383  |  | ** implementation must return a pointer to the page buffer with its content  | 
8384  |  | ** intact.  If the requested page is not already in the cache, then the  | 
8385  |  | ** cache implementation should use the value of the createFlag  | 
8386  |  | ** parameter to help it determined what action to take:  | 
8387  |  | **  | 
8388  |  | ** <table border=1 width=85% align=center>  | 
8389  |  | ** <tr><th> createFlag <th> Behavior when page is not already in cache  | 
8390  |  | ** <tr><td> 0 <td> Do not allocate a new page.  Return NULL.  | 
8391  |  | ** <tr><td> 1 <td> Allocate a new page if it easy and convenient to do so.  | 
8392  |  | **                 Otherwise return NULL.  | 
8393  |  | ** <tr><td> 2 <td> Make every effort to allocate a new page.  Only return  | 
8394  |  | **                 NULL if allocating a new page is effectively impossible.  | 
8395  |  | ** </table>  | 
8396  |  | **  | 
8397  |  | ** ^(SQLite will normally invoke xFetch() with a createFlag of 0 or 1.  SQLite  | 
8398  |  | ** will only use a createFlag of 2 after a prior call with a createFlag of 1  | 
8399  |  | ** failed.)^  In between the xFetch() calls, SQLite may  | 
8400  |  | ** attempt to unpin one or more cache pages by spilling the content of  | 
8401  |  | ** pinned pages to disk and synching the operating system disk cache.  | 
8402  |  | **  | 
8403  |  | ** [[the xUnpin() page cache method]]  | 
8404  |  | ** ^xUnpin() is called by SQLite with a pointer to a currently pinned page  | 
8405  |  | ** as its second argument.  If the third parameter, discard, is non-zero,  | 
8406  |  | ** then the page must be evicted from the cache.  | 
8407  |  | ** ^If the discard parameter is  | 
8408  |  | ** zero, then the page may be discarded or retained at the discretion of  | 
8409  |  | ** page cache implementation. ^The page cache implementation  | 
8410  |  | ** may choose to evict unpinned pages at any time.  | 
8411  |  | **  | 
8412  |  | ** The cache must not perform any reference counting. A single  | 
8413  |  | ** call to xUnpin() unpins the page regardless of the number of prior calls  | 
8414  |  | ** to xFetch().  | 
8415  |  | **  | 
8416  |  | ** [[the xRekey() page cache methods]]  | 
8417  |  | ** The xRekey() method is used to change the key value associated with the  | 
8418  |  | ** page passed as the second argument. If the cache  | 
8419  |  | ** previously contains an entry associated with newKey, it must be  | 
8420  |  | ** discarded. ^Any prior cache entry associated with newKey is guaranteed not  | 
8421  |  | ** to be pinned.  | 
8422  |  | **  | 
8423  |  | ** When SQLite calls the xTruncate() method, the cache must discard all  | 
8424  |  | ** existing cache entries with page numbers (keys) greater than or equal  | 
8425  |  | ** to the value of the iLimit parameter passed to xTruncate(). If any  | 
8426  |  | ** of these pages are pinned, they are implicitly unpinned, meaning that  | 
8427  |  | ** they can be safely discarded.  | 
8428  |  | **  | 
8429  |  | ** [[the xDestroy() page cache method]]  | 
8430  |  | ** ^The xDestroy() method is used to delete a cache allocated by xCreate().  | 
8431  |  | ** All resources associated with the specified cache should be freed. ^After  | 
8432  |  | ** calling the xDestroy() method, SQLite considers the [sqlite3_pcache*]  | 
8433  |  | ** handle invalid, and will not use it with any other sqlite3_pcache_methods2  | 
8434  |  | ** functions.  | 
8435  |  | **  | 
8436  |  | ** [[the xShrink() page cache method]]  | 
8437  |  | ** ^SQLite invokes the xShrink() method when it wants the page cache to  | 
8438  |  | ** free up as much of heap memory as possible.  The page cache implementation  | 
8439  |  | ** is not obligated to free any memory, but well-behaved implementations should  | 
8440  |  | ** do their best.  | 
8441  |  | */  | 
8442  |  | typedef struct sqlite3_pcache_methods2 sqlite3_pcache_methods2;  | 
8443  |  | struct sqlite3_pcache_methods2 { | 
8444  |  |   int iVersion;  | 
8445  |  |   void *pArg;  | 
8446  |  |   int (*xInit)(void*);  | 
8447  |  |   void (*xShutdown)(void*);  | 
8448  |  |   sqlite3_pcache *(*xCreate)(int szPage, int szExtra, int bPurgeable);  | 
8449  |  |   void (*xCachesize)(sqlite3_pcache*, int nCachesize);  | 
8450  |  |   int (*xPagecount)(sqlite3_pcache*);  | 
8451  |  |   sqlite3_pcache_page *(*xFetch)(sqlite3_pcache*, unsigned key, int createFlag);  | 
8452  |  |   void (*xUnpin)(sqlite3_pcache*, sqlite3_pcache_page*, int discard);  | 
8453  |  |   void (*xRekey)(sqlite3_pcache*, sqlite3_pcache_page*,  | 
8454  |  |       unsigned oldKey, unsigned newKey);  | 
8455  |  |   void (*xTruncate)(sqlite3_pcache*, unsigned iLimit);  | 
8456  |  |   void (*xDestroy)(sqlite3_pcache*);  | 
8457  |  |   void (*xShrink)(sqlite3_pcache*);  | 
8458  |  | };  | 
8459  |  |  | 
8460  |  | /*  | 
8461  |  | ** This is the obsolete pcache_methods object that has now been replaced  | 
8462  |  | ** by sqlite3_pcache_methods2.  This object is not used by SQLite.  It is  | 
8463  |  | ** retained in the header file for backwards compatibility only.  | 
8464  |  | */  | 
8465  |  | typedef struct sqlite3_pcache_methods sqlite3_pcache_methods;  | 
8466  |  | struct sqlite3_pcache_methods { | 
8467  |  |   void *pArg;  | 
8468  |  |   int (*xInit)(void*);  | 
8469  |  |   void (*xShutdown)(void*);  | 
8470  |  |   sqlite3_pcache *(*xCreate)(int szPage, int bPurgeable);  | 
8471  |  |   void (*xCachesize)(sqlite3_pcache*, int nCachesize);  | 
8472  |  |   int (*xPagecount)(sqlite3_pcache*);  | 
8473  |  |   void *(*xFetch)(sqlite3_pcache*, unsigned key, int createFlag);  | 
8474  |  |   void (*xUnpin)(sqlite3_pcache*, void*, int discard);  | 
8475  |  |   void (*xRekey)(sqlite3_pcache*, void*, unsigned oldKey, unsigned newKey);  | 
8476  |  |   void (*xTruncate)(sqlite3_pcache*, unsigned iLimit);  | 
8477  |  |   void (*xDestroy)(sqlite3_pcache*);  | 
8478  |  | };  | 
8479  |  |  | 
8480  |  |  | 
8481  |  | /*  | 
8482  |  | ** CAPI3REF: Online Backup Object  | 
8483  |  | **  | 
8484  |  | ** The sqlite3_backup object records state information about an ongoing  | 
8485  |  | ** online backup operation.  ^The sqlite3_backup object is created by  | 
8486  |  | ** a call to [sqlite3_backup_init()] and is destroyed by a call to  | 
8487  |  | ** [sqlite3_backup_finish()].  | 
8488  |  | **  | 
8489  |  | ** See Also: [Using the SQLite Online Backup API]  | 
8490  |  | */  | 
8491  |  | typedef struct sqlite3_backup sqlite3_backup;  | 
8492  |  |  | 
8493  |  | /*  | 
8494  |  | ** CAPI3REF: Online Backup API.  | 
8495  |  | **  | 
8496  |  | ** The backup API copies the content of one database into another.  | 
8497  |  | ** It is useful either for creating backups of databases or  | 
8498  |  | ** for copying in-memory databases to or from persistent files.  | 
8499  |  | **  | 
8500  |  | ** See Also: [Using the SQLite Online Backup API]  | 
8501  |  | **  | 
8502  |  | ** ^SQLite holds a write transaction open on the destination database file  | 
8503  |  | ** for the duration of the backup operation.  | 
8504  |  | ** ^The source database is read-locked only while it is being read;  | 
8505  |  | ** it is not locked continuously for the entire backup operation.  | 
8506  |  | ** ^Thus, the backup may be performed on a live source database without  | 
8507  |  | ** preventing other database connections from  | 
8508  |  | ** reading or writing to the source database while the backup is underway.  | 
8509  |  | **  | 
8510  |  | ** ^(To perform a backup operation:  | 
8511  |  | **   <ol>  | 
8512  |  | **     <li><b>sqlite3_backup_init()</b> is called once to initialize the  | 
8513  |  | **         backup,  | 
8514  |  | **     <li><b>sqlite3_backup_step()</b> is called one or more times to transfer  | 
8515  |  | **         the data between the two databases, and finally  | 
8516  |  | **     <li><b>sqlite3_backup_finish()</b> is called to release all resources  | 
8517  |  | **         associated with the backup operation.  | 
8518  |  | **   </ol>)^  | 
8519  |  | ** There should be exactly one call to sqlite3_backup_finish() for each  | 
8520  |  | ** successful call to sqlite3_backup_init().  | 
8521  |  | **  | 
8522  |  | ** [[sqlite3_backup_init()]] <b>sqlite3_backup_init()</b>  | 
8523  |  | **  | 
8524  |  | ** ^The D and N arguments to sqlite3_backup_init(D,N,S,M) are the  | 
8525  |  | ** [database connection] associated with the destination database  | 
8526  |  | ** and the database name, respectively.  | 
8527  |  | ** ^The database name is "main" for the main database, "temp" for the  | 
8528  |  | ** temporary database, or the name specified after the AS keyword in  | 
8529  |  | ** an [ATTACH] statement for an attached database.  | 
8530  |  | ** ^The S and M arguments passed to  | 
8531  |  | ** sqlite3_backup_init(D,N,S,M) identify the [database connection]  | 
8532  |  | ** and database name of the source database, respectively.  | 
8533  |  | ** ^The source and destination [database connections] (parameters S and D)  | 
8534  |  | ** must be different or else sqlite3_backup_init(D,N,S,M) will fail with  | 
8535  |  | ** an error.  | 
8536  |  | **  | 
8537  |  | ** ^A call to sqlite3_backup_init() will fail, returning NULL, if  | 
8538  |  | ** there is already a read or read-write transaction open on the  | 
8539  |  | ** destination database.  | 
8540  |  | **  | 
8541  |  | ** ^If an error occurs within sqlite3_backup_init(D,N,S,M), then NULL is  | 
8542  |  | ** returned and an error code and error message are stored in the  | 
8543  |  | ** destination [database connection] D.  | 
8544  |  | ** ^The error code and message for the failed call to sqlite3_backup_init()  | 
8545  |  | ** can be retrieved using the [sqlite3_errcode()], [sqlite3_errmsg()], and/or  | 
8546  |  | ** [sqlite3_errmsg16()] functions.  | 
8547  |  | ** ^A successful call to sqlite3_backup_init() returns a pointer to an  | 
8548  |  | ** [sqlite3_backup] object.  | 
8549  |  | ** ^The [sqlite3_backup] object may be used with the sqlite3_backup_step() and  | 
8550  |  | ** sqlite3_backup_finish() functions to perform the specified backup  | 
8551  |  | ** operation.  | 
8552  |  | **  | 
8553  |  | ** [[sqlite3_backup_step()]] <b>sqlite3_backup_step()</b>  | 
8554  |  | **  | 
8555  |  | ** ^Function sqlite3_backup_step(B,N) will copy up to N pages between  | 
8556  |  | ** the source and destination databases specified by [sqlite3_backup] object B.  | 
8557  |  | ** ^If N is negative, all remaining source pages are copied.  | 
8558  |  | ** ^If sqlite3_backup_step(B,N) successfully copies N pages and there  | 
8559  |  | ** are still more pages to be copied, then the function returns [SQLITE_OK].  | 
8560  |  | ** ^If sqlite3_backup_step(B,N) successfully finishes copying all pages  | 
8561  |  | ** from source to destination, then it returns [SQLITE_DONE].  | 
8562  |  | ** ^If an error occurs while running sqlite3_backup_step(B,N),  | 
8563  |  | ** then an [error code] is returned. ^As well as [SQLITE_OK] and  | 
8564  |  | ** [SQLITE_DONE], a call to sqlite3_backup_step() may return [SQLITE_READONLY],  | 
8565  |  | ** [SQLITE_NOMEM], [SQLITE_BUSY], [SQLITE_LOCKED], or an  | 
8566  |  | ** [SQLITE_IOERR_ACCESS | SQLITE_IOERR_XXX] extended error code.  | 
8567  |  | **  | 
8568  |  | ** ^(The sqlite3_backup_step() might return [SQLITE_READONLY] if  | 
8569  |  | ** <ol>  | 
8570  |  | ** <li> the destination database was opened read-only, or  | 
8571  |  | ** <li> the destination database is using write-ahead-log journaling  | 
8572  |  | ** and the destination and source page sizes differ, or  | 
8573  |  | ** <li> the destination database is an in-memory database and the  | 
8574  |  | ** destination and source page sizes differ.  | 
8575  |  | ** </ol>)^  | 
8576  |  | **  | 
8577  |  | ** ^If sqlite3_backup_step() cannot obtain a required file-system lock, then  | 
8578  |  | ** the [sqlite3_busy_handler | busy-handler function]  | 
8579  |  | ** is invoked (if one is specified). ^If the  | 
8580  |  | ** busy-handler returns non-zero before the lock is available, then  | 
8581  |  | ** [SQLITE_BUSY] is returned to the caller. ^In this case the call to  | 
8582  |  | ** sqlite3_backup_step() can be retried later. ^If the source  | 
8583  |  | ** [database connection]  | 
8584  |  | ** is being used to write to the source database when sqlite3_backup_step()  | 
8585  |  | ** is called, then [SQLITE_LOCKED] is returned immediately. ^Again, in this  | 
8586  |  | ** case the call to sqlite3_backup_step() can be retried later on. ^(If  | 
8587  |  | ** [SQLITE_IOERR_ACCESS | SQLITE_IOERR_XXX], [SQLITE_NOMEM], or  | 
8588  |  | ** [SQLITE_READONLY] is returned, then  | 
8589  |  | ** there is no point in retrying the call to sqlite3_backup_step(). These  | 
8590  |  | ** errors are considered fatal.)^  The application must accept  | 
8591  |  | ** that the backup operation has failed and pass the backup operation handle  | 
8592  |  | ** to the sqlite3_backup_finish() to release associated resources.  | 
8593  |  | **  | 
8594  |  | ** ^The first call to sqlite3_backup_step() obtains an exclusive lock  | 
8595  |  | ** on the destination file. ^The exclusive lock is not released until either  | 
8596  |  | ** sqlite3_backup_finish() is called or the backup operation is complete  | 
8597  |  | ** and sqlite3_backup_step() returns [SQLITE_DONE].  ^Every call to  | 
8598  |  | ** sqlite3_backup_step() obtains a [shared lock] on the source database that  | 
8599  |  | ** lasts for the duration of the sqlite3_backup_step() call.  | 
8600  |  | ** ^Because the source database is not locked between calls to  | 
8601  |  | ** sqlite3_backup_step(), the source database may be modified mid-way  | 
8602  |  | ** through the backup process.  ^If the source database is modified by an  | 
8603  |  | ** external process or via a database connection other than the one being  | 
8604  |  | ** used by the backup operation, then the backup will be automatically  | 
8605  |  | ** restarted by the next call to sqlite3_backup_step(). ^If the source  | 
8606  |  | ** database is modified by the using the same database connection as is used  | 
8607  |  | ** by the backup operation, then the backup database is automatically  | 
8608  |  | ** updated at the same time.  | 
8609  |  | **  | 
8610  |  | ** [[sqlite3_backup_finish()]] <b>sqlite3_backup_finish()</b>  | 
8611  |  | **  | 
8612  |  | ** When sqlite3_backup_step() has returned [SQLITE_DONE], or when the  | 
8613  |  | ** application wishes to abandon the backup operation, the application  | 
8614  |  | ** should destroy the [sqlite3_backup] by passing it to sqlite3_backup_finish().  | 
8615  |  | ** ^The sqlite3_backup_finish() interfaces releases all  | 
8616  |  | ** resources associated with the [sqlite3_backup] object.  | 
8617  |  | ** ^If sqlite3_backup_step() has not yet returned [SQLITE_DONE], then any  | 
8618  |  | ** active write-transaction on the destination database is rolled back.  | 
8619  |  | ** The [sqlite3_backup] object is invalid  | 
8620  |  | ** and may not be used following a call to sqlite3_backup_finish().  | 
8621  |  | **  | 
8622  |  | ** ^The value returned by sqlite3_backup_finish is [SQLITE_OK] if no  | 
8623  |  | ** sqlite3_backup_step() errors occurred, regardless or whether or not  | 
8624  |  | ** sqlite3_backup_step() completed.  | 
8625  |  | ** ^If an out-of-memory condition or IO error occurred during any prior  | 
8626  |  | ** sqlite3_backup_step() call on the same [sqlite3_backup] object, then  | 
8627  |  | ** sqlite3_backup_finish() returns the corresponding [error code].  | 
8628  |  | **  | 
8629  |  | ** ^A return of [SQLITE_BUSY] or [SQLITE_LOCKED] from sqlite3_backup_step()  | 
8630  |  | ** is not a permanent error and does not affect the return value of  | 
8631  |  | ** sqlite3_backup_finish().  | 
8632  |  | **  | 
8633  |  | ** [[sqlite3_backup_remaining()]] [[sqlite3_backup_pagecount()]]  | 
8634  |  | ** <b>sqlite3_backup_remaining() and sqlite3_backup_pagecount()</b>  | 
8635  |  | **  | 
8636  |  | ** ^The sqlite3_backup_remaining() routine returns the number of pages still  | 
8637  |  | ** to be backed up at the conclusion of the most recent sqlite3_backup_step().  | 
8638  |  | ** ^The sqlite3_backup_pagecount() routine returns the total number of pages  | 
8639  |  | ** in the source database at the conclusion of the most recent  | 
8640  |  | ** sqlite3_backup_step().  | 
8641  |  | ** ^(The values returned by these functions are only updated by  | 
8642  |  | ** sqlite3_backup_step(). If the source database is modified in a way that  | 
8643  |  | ** changes the size of the source database or the number of pages remaining,  | 
8644  |  | ** those changes are not reflected in the output of sqlite3_backup_pagecount()  | 
8645  |  | ** and sqlite3_backup_remaining() until after the next  | 
8646  |  | ** sqlite3_backup_step().)^  | 
8647  |  | **  | 
8648  |  | ** <b>Concurrent Usage of Database Handles</b>  | 
8649  |  | **  | 
8650  |  | ** ^The source [database connection] may be used by the application for other  | 
8651  |  | ** purposes while a backup operation is underway or being initialized.  | 
8652  |  | ** ^If SQLite is compiled and configured to support threadsafe database  | 
8653  |  | ** connections, then the source database connection may be used concurrently  | 
8654  |  | ** from within other threads.  | 
8655  |  | **  | 
8656  |  | ** However, the application must guarantee that the destination  | 
8657  |  | ** [database connection] is not passed to any other API (by any thread) after  | 
8658  |  | ** sqlite3_backup_init() is called and before the corresponding call to  | 
8659  |  | ** sqlite3_backup_finish().  SQLite does not currently check to see  | 
8660  |  | ** if the application incorrectly accesses the destination [database connection]  | 
8661  |  | ** and so no error code is reported, but the operations may malfunction  | 
8662  |  | ** nevertheless.  Use of the destination database connection while a  | 
8663  |  | ** backup is in progress might also also cause a mutex deadlock.  | 
8664  |  | **  | 
8665  |  | ** If running in [shared cache mode], the application must  | 
8666  |  | ** guarantee that the shared cache used by the destination database  | 
8667  |  | ** is not accessed while the backup is running. In practice this means  | 
8668  |  | ** that the application must guarantee that the disk file being  | 
8669  |  | ** backed up to is not accessed by any connection within the process,  | 
8670  |  | ** not just the specific connection that was passed to sqlite3_backup_init().  | 
8671  |  | **  | 
8672  |  | ** The [sqlite3_backup] object itself is partially threadsafe. Multiple  | 
8673  |  | ** threads may safely make multiple concurrent calls to sqlite3_backup_step().  | 
8674  |  | ** However, the sqlite3_backup_remaining() and sqlite3_backup_pagecount()  | 
8675  |  | ** APIs are not strictly speaking threadsafe. If they are invoked at the  | 
8676  |  | ** same time as another thread is invoking sqlite3_backup_step() it is  | 
8677  |  | ** possible that they return invalid values.  | 
8678  |  | */  | 
8679  |  | SQLITE_API sqlite3_backup *sqlite3_backup_init(  | 
8680  |  |   sqlite3 *pDest,                        /* Destination database handle */  | 
8681  |  |   const char *zDestName,                 /* Destination database name */  | 
8682  |  |   sqlite3 *pSource,                      /* Source database handle */  | 
8683  |  |   const char *zSourceName                /* Source database name */  | 
8684  |  | );  | 
8685  |  | SQLITE_API int sqlite3_backup_step(sqlite3_backup *p, int nPage);  | 
8686  |  | SQLITE_API int sqlite3_backup_finish(sqlite3_backup *p);  | 
8687  |  | SQLITE_API int sqlite3_backup_remaining(sqlite3_backup *p);  | 
8688  |  | SQLITE_API int sqlite3_backup_pagecount(sqlite3_backup *p);  | 
8689  |  |  | 
8690  |  | /*  | 
8691  |  | ** CAPI3REF: Unlock Notification  | 
8692  |  | ** METHOD: sqlite3  | 
8693  |  | **  | 
8694  |  | ** ^When running in shared-cache mode, a database operation may fail with  | 
8695  |  | ** an [SQLITE_LOCKED] error if the required locks on the shared-cache or  | 
8696  |  | ** individual tables within the shared-cache cannot be obtained. See  | 
8697  |  | ** [SQLite Shared-Cache Mode] for a description of shared-cache locking.  | 
8698  |  | ** ^This API may be used to register a callback that SQLite will invoke  | 
8699  |  | ** when the connection currently holding the required lock relinquishes it.  | 
8700  |  | ** ^This API is only available if the library was compiled with the  | 
8701  |  | ** [SQLITE_ENABLE_UNLOCK_NOTIFY] C-preprocessor symbol defined.  | 
8702  |  | **  | 
8703  |  | ** See Also: [Using the SQLite Unlock Notification Feature].  | 
8704  |  | **  | 
8705  |  | ** ^Shared-cache locks are released when a database connection concludes  | 
8706  |  | ** its current transaction, either by committing it or rolling it back.  | 
8707  |  | **  | 
8708  |  | ** ^When a connection (known as the blocked connection) fails to obtain a  | 
8709  |  | ** shared-cache lock and SQLITE_LOCKED is returned to the caller, the  | 
8710  |  | ** identity of the database connection (the blocking connection) that  | 
8711  |  | ** has locked the required resource is stored internally. ^After an  | 
8712  |  | ** application receives an SQLITE_LOCKED error, it may call the  | 
8713  |  | ** sqlite3_unlock_notify() method with the blocked connection handle as  | 
8714  |  | ** the first argument to register for a callback that will be invoked  | 
8715  |  | ** when the blocking connections current transaction is concluded. ^The  | 
8716  |  | ** callback is invoked from within the [sqlite3_step] or [sqlite3_close]  | 
8717  |  | ** call that concludes the blocking connection's transaction.  | 
8718  |  | **  | 
8719  |  | ** ^(If sqlite3_unlock_notify() is called in a multi-threaded application,  | 
8720  |  | ** there is a chance that the blocking connection will have already  | 
8721  |  | ** concluded its transaction by the time sqlite3_unlock_notify() is invoked.  | 
8722  |  | ** If this happens, then the specified callback is invoked immediately,  | 
8723  |  | ** from within the call to sqlite3_unlock_notify().)^  | 
8724  |  | **  | 
8725  |  | ** ^If the blocked connection is attempting to obtain a write-lock on a  | 
8726  |  | ** shared-cache table, and more than one other connection currently holds  | 
8727  |  | ** a read-lock on the same table, then SQLite arbitrarily selects one of  | 
8728  |  | ** the other connections to use as the blocking connection.  | 
8729  |  | **  | 
8730  |  | ** ^(There may be at most one unlock-notify callback registered by a  | 
8731  |  | ** blocked connection. If sqlite3_unlock_notify() is called when the  | 
8732  |  | ** blocked connection already has a registered unlock-notify callback,  | 
8733  |  | ** then the new callback replaces the old.)^ ^If sqlite3_unlock_notify() is  | 
8734  |  | ** called with a NULL pointer as its second argument, then any existing  | 
8735  |  | ** unlock-notify callback is canceled. ^The blocked connections  | 
8736  |  | ** unlock-notify callback may also be canceled by closing the blocked  | 
8737  |  | ** connection using [sqlite3_close()].  | 
8738  |  | **  | 
8739  |  | ** The unlock-notify callback is not reentrant. If an application invokes  | 
8740  |  | ** any sqlite3_xxx API functions from within an unlock-notify callback, a  | 
8741  |  | ** crash or deadlock may be the result.  | 
8742  |  | **  | 
8743  |  | ** ^Unless deadlock is detected (see below), sqlite3_unlock_notify() always  | 
8744  |  | ** returns SQLITE_OK.  | 
8745  |  | **  | 
8746  |  | ** <b>Callback Invocation Details</b>  | 
8747  |  | **  | 
8748  |  | ** When an unlock-notify callback is registered, the application provides a  | 
8749  |  | ** single void* pointer that is passed to the callback when it is invoked.  | 
8750  |  | ** However, the signature of the callback function allows SQLite to pass  | 
8751  |  | ** it an array of void* context pointers. The first argument passed to  | 
8752  |  | ** an unlock-notify callback is a pointer to an array of void* pointers,  | 
8753  |  | ** and the second is the number of entries in the array.  | 
8754  |  | **  | 
8755  |  | ** When a blocking connection's transaction is concluded, there may be  | 
8756  |  | ** more than one blocked connection that has registered for an unlock-notify  | 
8757  |  | ** callback. ^If two or more such blocked connections have specified the  | 
8758  |  | ** same callback function, then instead of invoking the callback function  | 
8759  |  | ** multiple times, it is invoked once with the set of void* context pointers  | 
8760  |  | ** specified by the blocked connections bundled together into an array.  | 
8761  |  | ** This gives the application an opportunity to prioritize any actions  | 
8762  |  | ** related to the set of unblocked database connections.  | 
8763  |  | **  | 
8764  |  | ** <b>Deadlock Detection</b>  | 
8765  |  | **  | 
8766  |  | ** Assuming that after registering for an unlock-notify callback a  | 
8767  |  | ** database waits for the callback to be issued before taking any further  | 
8768  |  | ** action (a reasonable assumption), then using this API may cause the  | 
8769  |  | ** application to deadlock. For example, if connection X is waiting for  | 
8770  |  | ** connection Y's transaction to be concluded, and similarly connection  | 
8771  |  | ** Y is waiting on connection X's transaction, then neither connection  | 
8772  |  | ** will proceed and the system may remain deadlocked indefinitely.  | 
8773  |  | **  | 
8774  |  | ** To avoid this scenario, the sqlite3_unlock_notify() performs deadlock  | 
8775  |  | ** detection. ^If a given call to sqlite3_unlock_notify() would put the  | 
8776  |  | ** system in a deadlocked state, then SQLITE_LOCKED is returned and no  | 
8777  |  | ** unlock-notify callback is registered. The system is said to be in  | 
8778  |  | ** a deadlocked state if connection A has registered for an unlock-notify  | 
8779  |  | ** callback on the conclusion of connection B's transaction, and connection  | 
8780  |  | ** B has itself registered for an unlock-notify callback when connection  | 
8781  |  | ** A's transaction is concluded. ^Indirect deadlock is also detected, so  | 
8782  |  | ** the system is also considered to be deadlocked if connection B has  | 
8783  |  | ** registered for an unlock-notify callback on the conclusion of connection  | 
8784  |  | ** C's transaction, where connection C is waiting on connection A. ^Any  | 
8785  |  | ** number of levels of indirection are allowed.  | 
8786  |  | **  | 
8787  |  | ** <b>The "DROP TABLE" Exception</b>  | 
8788  |  | **  | 
8789  |  | ** When a call to [sqlite3_step()] returns SQLITE_LOCKED, it is almost  | 
8790  |  | ** always appropriate to call sqlite3_unlock_notify(). There is however,  | 
8791  |  | ** one exception. When executing a "DROP TABLE" or "DROP INDEX" statement,  | 
8792  |  | ** SQLite checks if there are any currently executing SELECT statements  | 
8793  |  | ** that belong to the same connection. If there are, SQLITE_LOCKED is  | 
8794  |  | ** returned. In this case there is no "blocking connection", so invoking  | 
8795  |  | ** sqlite3_unlock_notify() results in the unlock-notify callback being  | 
8796  |  | ** invoked immediately. If the application then re-attempts the "DROP TABLE"  | 
8797  |  | ** or "DROP INDEX" query, an infinite loop might be the result.  | 
8798  |  | **  | 
8799  |  | ** One way around this problem is to check the extended error code returned  | 
8800  |  | ** by an sqlite3_step() call. ^(If there is a blocking connection, then the  | 
8801  |  | ** extended error code is set to SQLITE_LOCKED_SHAREDCACHE. Otherwise, in  | 
8802  |  | ** the special "DROP TABLE/INDEX" case, the extended error code is just  | 
8803  |  | ** SQLITE_LOCKED.)^  | 
8804  |  | */  | 
8805  |  | SQLITE_API int sqlite3_unlock_notify(  | 
8806  |  |   sqlite3 *pBlocked,                          /* Waiting connection */  | 
8807  |  |   void (*xNotify)(void **apArg, int nArg),    /* Callback function to invoke */  | 
8808  |  |   void *pNotifyArg                            /* Argument to pass to xNotify */  | 
8809  |  | );  | 
8810  |  |  | 
8811  |  |  | 
8812  |  | /*  | 
8813  |  | ** CAPI3REF: String Comparison  | 
8814  |  | **  | 
8815  |  | ** ^The [sqlite3_stricmp()] and [sqlite3_strnicmp()] APIs allow applications  | 
8816  |  | ** and extensions to compare the contents of two buffers containing UTF-8  | 
8817  |  | ** strings in a case-independent fashion, using the same definition of "case  | 
8818  |  | ** independence" that SQLite uses internally when comparing identifiers.  | 
8819  |  | */  | 
8820  |  | SQLITE_API int sqlite3_stricmp(const char *, const char *);  | 
8821  |  | SQLITE_API int sqlite3_strnicmp(const char *, const char *, int);  | 
8822  |  |  | 
8823  |  | /*  | 
8824  |  | ** CAPI3REF: String Globbing  | 
8825  |  | *  | 
8826  |  | ** ^The [sqlite3_strglob(P,X)] interface returns zero if and only if  | 
8827  |  | ** string X matches the [GLOB] pattern P.  | 
8828  |  | ** ^The definition of [GLOB] pattern matching used in  | 
8829  |  | ** [sqlite3_strglob(P,X)] is the same as for the "X GLOB P" operator in the  | 
8830  |  | ** SQL dialect understood by SQLite.  ^The [sqlite3_strglob(P,X)] function  | 
8831  |  | ** is case sensitive.  | 
8832  |  | **  | 
8833  |  | ** Note that this routine returns zero on a match and non-zero if the strings  | 
8834  |  | ** do not match, the same as [sqlite3_stricmp()] and [sqlite3_strnicmp()].  | 
8835  |  | **  | 
8836  |  | ** See also: [sqlite3_strlike()].  | 
8837  |  | */  | 
8838  |  | SQLITE_API int sqlite3_strglob(const char *zGlob, const char *zStr);  | 
8839  |  |  | 
8840  |  | /*  | 
8841  |  | ** CAPI3REF: String LIKE Matching  | 
8842  |  | *  | 
8843  |  | ** ^The [sqlite3_strlike(P,X,E)] interface returns zero if and only if  | 
8844  |  | ** string X matches the [LIKE] pattern P with escape character E.  | 
8845  |  | ** ^The definition of [LIKE] pattern matching used in  | 
8846  |  | ** [sqlite3_strlike(P,X,E)] is the same as for the "X LIKE P ESCAPE E"  | 
8847  |  | ** operator in the SQL dialect understood by SQLite.  ^For "X LIKE P" without  | 
8848  |  | ** the ESCAPE clause, set the E parameter of [sqlite3_strlike(P,X,E)] to 0.  | 
8849  |  | ** ^As with the LIKE operator, the [sqlite3_strlike(P,X,E)] function is case  | 
8850  |  | ** insensitive - equivalent upper and lower case ASCII characters match  | 
8851  |  | ** one another.  | 
8852  |  | **  | 
8853  |  | ** ^The [sqlite3_strlike(P,X,E)] function matches Unicode characters, though  | 
8854  |  | ** only ASCII characters are case folded.  | 
8855  |  | **  | 
8856  |  | ** Note that this routine returns zero on a match and non-zero if the strings  | 
8857  |  | ** do not match, the same as [sqlite3_stricmp()] and [sqlite3_strnicmp()].  | 
8858  |  | **  | 
8859  |  | ** See also: [sqlite3_strglob()].  | 
8860  |  | */  | 
8861  |  | SQLITE_API int sqlite3_strlike(const char *zGlob, const char *zStr, unsigned int cEsc);  | 
8862  |  |  | 
8863  |  | /*  | 
8864  |  | ** CAPI3REF: Error Logging Interface  | 
8865  |  | **  | 
8866  |  | ** ^The [sqlite3_log()] interface writes a message into the [error log]  | 
8867  |  | ** established by the [SQLITE_CONFIG_LOG] option to [sqlite3_config()].  | 
8868  |  | ** ^If logging is enabled, the zFormat string and subsequent arguments are  | 
8869  |  | ** used with [sqlite3_snprintf()] to generate the final output string.  | 
8870  |  | **  | 
8871  |  | ** The sqlite3_log() interface is intended for use by extensions such as  | 
8872  |  | ** virtual tables, collating functions, and SQL functions.  While there is  | 
8873  |  | ** nothing to prevent an application from calling sqlite3_log(), doing so  | 
8874  |  | ** is considered bad form.  | 
8875  |  | **  | 
8876  |  | ** The zFormat string must not be NULL.  | 
8877  |  | **  | 
8878  |  | ** To avoid deadlocks and other threading problems, the sqlite3_log() routine  | 
8879  |  | ** will not use dynamically allocated memory.  The log message is stored in  | 
8880  |  | ** a fixed-length buffer on the stack.  If the log message is longer than  | 
8881  |  | ** a few hundred characters, it will be truncated to the length of the  | 
8882  |  | ** buffer.  | 
8883  |  | */  | 
8884  |  | SQLITE_API void sqlite3_log(int iErrCode, const char *zFormat, ...);  | 
8885  |  |  | 
8886  |  | /*  | 
8887  |  | ** CAPI3REF: Write-Ahead Log Commit Hook  | 
8888  |  | ** METHOD: sqlite3  | 
8889  |  | **  | 
8890  |  | ** ^The [sqlite3_wal_hook()] function is used to register a callback that  | 
8891  |  | ** is invoked each time data is committed to a database in wal mode.  | 
8892  |  | **  | 
8893  |  | ** ^(The callback is invoked by SQLite after the commit has taken place and  | 
8894  |  | ** the associated write-lock on the database released)^, so the implementation  | 
8895  |  | ** may read, write or [checkpoint] the database as required.  | 
8896  |  | **  | 
8897  |  | ** ^The first parameter passed to the callback function when it is invoked  | 
8898  |  | ** is a copy of the third parameter passed to sqlite3_wal_hook() when  | 
8899  |  | ** registering the callback. ^The second is a copy of the database handle.  | 
8900  |  | ** ^The third parameter is the name of the database that was written to -  | 
8901  |  | ** either "main" or the name of an [ATTACH]-ed database. ^The fourth parameter  | 
8902  |  | ** is the number of pages currently in the write-ahead log file,  | 
8903  |  | ** including those that were just committed.  | 
8904  |  | **  | 
8905  |  | ** The callback function should normally return [SQLITE_OK].  ^If an error  | 
8906  |  | ** code is returned, that error will propagate back up through the  | 
8907  |  | ** SQLite code base to cause the statement that provoked the callback  | 
8908  |  | ** to report an error, though the commit will have still occurred. If the  | 
8909  |  | ** callback returns [SQLITE_ROW] or [SQLITE_DONE], or if it returns a value  | 
8910  |  | ** that does not correspond to any valid SQLite error code, the results  | 
8911  |  | ** are undefined.  | 
8912  |  | **  | 
8913  |  | ** A single database handle may have at most a single write-ahead log callback  | 
8914  |  | ** registered at one time. ^Calling [sqlite3_wal_hook()] replaces any  | 
8915  |  | ** previously registered write-ahead log callback. ^Note that the  | 
8916  |  | ** [sqlite3_wal_autocheckpoint()] interface and the  | 
8917  |  | ** [wal_autocheckpoint pragma] both invoke [sqlite3_wal_hook()] and will  | 
8918  |  | ** overwrite any prior [sqlite3_wal_hook()] settings.  | 
8919  |  | */  | 
8920  |  | SQLITE_API void *sqlite3_wal_hook(  | 
8921  |  |   sqlite3*,  | 
8922  |  |   int(*)(void *,sqlite3*,const char*,int),  | 
8923  |  |   void*  | 
8924  |  | );  | 
8925  |  |  | 
8926  |  | /*  | 
8927  |  | ** CAPI3REF: Configure an auto-checkpoint  | 
8928  |  | ** METHOD: sqlite3  | 
8929  |  | **  | 
8930  |  | ** ^The [sqlite3_wal_autocheckpoint(D,N)] is a wrapper around  | 
8931  |  | ** [sqlite3_wal_hook()] that causes any database on [database connection] D  | 
8932  |  | ** to automatically [checkpoint]  | 
8933  |  | ** after committing a transaction if there are N or  | 
8934  |  | ** more frames in the [write-ahead log] file.  ^Passing zero or  | 
8935  |  | ** a negative value as the nFrame parameter disables automatic  | 
8936  |  | ** checkpoints entirely.  | 
8937  |  | **  | 
8938  |  | ** ^The callback registered by this function replaces any existing callback  | 
8939  |  | ** registered using [sqlite3_wal_hook()].  ^Likewise, registering a callback  | 
8940  |  | ** using [sqlite3_wal_hook()] disables the automatic checkpoint mechanism  | 
8941  |  | ** configured by this function.  | 
8942  |  | **  | 
8943  |  | ** ^The [wal_autocheckpoint pragma] can be used to invoke this interface  | 
8944  |  | ** from SQL.  | 
8945  |  | **  | 
8946  |  | ** ^Checkpoints initiated by this mechanism are  | 
8947  |  | ** [sqlite3_wal_checkpoint_v2|PASSIVE].  | 
8948  |  | **  | 
8949  |  | ** ^Every new [database connection] defaults to having the auto-checkpoint  | 
8950  |  | ** enabled with a threshold of 1000 or [SQLITE_DEFAULT_WAL_AUTOCHECKPOINT]  | 
8951  |  | ** pages.  The use of this interface  | 
8952  |  | ** is only necessary if the default setting is found to be suboptimal  | 
8953  |  | ** for a particular application.  | 
8954  |  | */  | 
8955  |  | SQLITE_API int sqlite3_wal_autocheckpoint(sqlite3 *db, int N);  | 
8956  |  |  | 
8957  |  | /*  | 
8958  |  | ** CAPI3REF: Checkpoint a database  | 
8959  |  | ** METHOD: sqlite3  | 
8960  |  | **  | 
8961  |  | ** ^(The sqlite3_wal_checkpoint(D,X) is equivalent to  | 
8962  |  | ** [sqlite3_wal_checkpoint_v2](D,X,[SQLITE_CHECKPOINT_PASSIVE],0,0).)^  | 
8963  |  | **  | 
8964  |  | ** In brief, sqlite3_wal_checkpoint(D,X) causes the content in the  | 
8965  |  | ** [write-ahead log] for database X on [database connection] D to be  | 
8966  |  | ** transferred into the database file and for the write-ahead log to  | 
8967  |  | ** be reset.  See the [checkpointing] documentation for addition  | 
8968  |  | ** information.  | 
8969  |  | **  | 
8970  |  | ** This interface used to be the only way to cause a checkpoint to  | 
8971  |  | ** occur.  But then the newer and more powerful [sqlite3_wal_checkpoint_v2()]  | 
8972  |  | ** interface was added.  This interface is retained for backwards  | 
8973  |  | ** compatibility and as a convenience for applications that need to manually  | 
8974  |  | ** start a callback but which do not need the full power (and corresponding  | 
8975  |  | ** complication) of [sqlite3_wal_checkpoint_v2()].  | 
8976  |  | */  | 
8977  |  | SQLITE_API int sqlite3_wal_checkpoint(sqlite3 *db, const char *zDb);  | 
8978  |  |  | 
8979  |  | /*  | 
8980  |  | ** CAPI3REF: Checkpoint a database  | 
8981  |  | ** METHOD: sqlite3  | 
8982  |  | **  | 
8983  |  | ** ^(The sqlite3_wal_checkpoint_v2(D,X,M,L,C) interface runs a checkpoint  | 
8984  |  | ** operation on database X of [database connection] D in mode M.  Status  | 
8985  |  | ** information is written back into integers pointed to by L and C.)^  | 
8986  |  | ** ^(The M parameter must be a valid [checkpoint mode]:)^  | 
8987  |  | **  | 
8988  |  | ** <dl>  | 
8989  |  | ** <dt>SQLITE_CHECKPOINT_PASSIVE<dd>  | 
8990  |  | **   ^Checkpoint as many frames as possible without waiting for any database  | 
8991  |  | **   readers or writers to finish, then sync the database file if all frames  | 
8992  |  | **   in the log were checkpointed. ^The [busy-handler callback]  | 
8993  |  | **   is never invoked in the SQLITE_CHECKPOINT_PASSIVE mode.  | 
8994  |  | **   ^On the other hand, passive mode might leave the checkpoint unfinished  | 
8995  |  | **   if there are concurrent readers or writers.  | 
8996  |  | **  | 
8997  |  | ** <dt>SQLITE_CHECKPOINT_FULL<dd>  | 
8998  |  | **   ^This mode blocks (it invokes the  | 
8999  |  | **   [sqlite3_busy_handler|busy-handler callback]) until there is no  | 
9000  |  | **   database writer and all readers are reading from the most recent database  | 
9001  |  | **   snapshot. ^It then checkpoints all frames in the log file and syncs the  | 
9002  |  | **   database file. ^This mode blocks new database writers while it is pending,  | 
9003  |  | **   but new database readers are allowed to continue unimpeded.  | 
9004  |  | **  | 
9005  |  | ** <dt>SQLITE_CHECKPOINT_RESTART<dd>  | 
9006  |  | **   ^This mode works the same way as SQLITE_CHECKPOINT_FULL with the addition  | 
9007  |  | **   that after checkpointing the log file it blocks (calls the  | 
9008  |  | **   [busy-handler callback])  | 
9009  |  | **   until all readers are reading from the database file only. ^This ensures  | 
9010  |  | **   that the next writer will restart the log file from the beginning.  | 
9011  |  | **   ^Like SQLITE_CHECKPOINT_FULL, this mode blocks new  | 
9012  |  | **   database writer attempts while it is pending, but does not impede readers.  | 
9013  |  | **  | 
9014  |  | ** <dt>SQLITE_CHECKPOINT_TRUNCATE<dd>  | 
9015  |  | **   ^This mode works the same way as SQLITE_CHECKPOINT_RESTART with the  | 
9016  |  | **   addition that it also truncates the log file to zero bytes just prior  | 
9017  |  | **   to a successful return.  | 
9018  |  | ** </dl>  | 
9019  |  | **  | 
9020  |  | ** ^If pnLog is not NULL, then *pnLog is set to the total number of frames in  | 
9021  |  | ** the log file or to -1 if the checkpoint could not run because  | 
9022  |  | ** of an error or because the database is not in [WAL mode]. ^If pnCkpt is not  | 
9023  |  | ** NULL,then *pnCkpt is set to the total number of checkpointed frames in the  | 
9024  |  | ** log file (including any that were already checkpointed before the function  | 
9025  |  | ** was called) or to -1 if the checkpoint could not run due to an error or  | 
9026  |  | ** because the database is not in WAL mode. ^Note that upon successful  | 
9027  |  | ** completion of an SQLITE_CHECKPOINT_TRUNCATE, the log file will have been  | 
9028  |  | ** truncated to zero bytes and so both *pnLog and *pnCkpt will be set to zero.  | 
9029  |  | **  | 
9030  |  | ** ^All calls obtain an exclusive "checkpoint" lock on the database file. ^If  | 
9031  |  | ** any other process is running a checkpoint operation at the same time, the  | 
9032  |  | ** lock cannot be obtained and SQLITE_BUSY is returned. ^Even if there is a  | 
9033  |  | ** busy-handler configured, it will not be invoked in this case.  | 
9034  |  | **  | 
9035  |  | ** ^The SQLITE_CHECKPOINT_FULL, RESTART and TRUNCATE modes also obtain the  | 
9036  |  | ** exclusive "writer" lock on the database file. ^If the writer lock cannot be  | 
9037  |  | ** obtained immediately, and a busy-handler is configured, it is invoked and  | 
9038  |  | ** the writer lock retried until either the busy-handler returns 0 or the lock  | 
9039  |  | ** is successfully obtained. ^The busy-handler is also invoked while waiting for  | 
9040  |  | ** database readers as described above. ^If the busy-handler returns 0 before  | 
9041  |  | ** the writer lock is obtained or while waiting for database readers, the  | 
9042  |  | ** checkpoint operation proceeds from that point in the same way as  | 
9043  |  | ** SQLITE_CHECKPOINT_PASSIVE - checkpointing as many frames as possible  | 
9044  |  | ** without blocking any further. ^SQLITE_BUSY is returned in this case.  | 
9045  |  | **  | 
9046  |  | ** ^If parameter zDb is NULL or points to a zero length string, then the  | 
9047  |  | ** specified operation is attempted on all WAL databases [attached] to  | 
9048  |  | ** [database connection] db.  In this case the  | 
9049  |  | ** values written to output parameters *pnLog and *pnCkpt are undefined. ^If  | 
9050  |  | ** an SQLITE_BUSY error is encountered when processing one or more of the  | 
9051  |  | ** attached WAL databases, the operation is still attempted on any remaining  | 
9052  |  | ** attached databases and SQLITE_BUSY is returned at the end. ^If any other  | 
9053  |  | ** error occurs while processing an attached database, processing is abandoned  | 
9054  |  | ** and the error code is returned to the caller immediately. ^If no error  | 
9055  |  | ** (SQLITE_BUSY or otherwise) is encountered while processing the attached  | 
9056  |  | ** databases, SQLITE_OK is returned.  | 
9057  |  | **  | 
9058  |  | ** ^If database zDb is the name of an attached database that is not in WAL  | 
9059  |  | ** mode, SQLITE_OK is returned and both *pnLog and *pnCkpt set to -1. ^If  | 
9060  |  | ** zDb is not NULL (or a zero length string) and is not the name of any  | 
9061  |  | ** attached database, SQLITE_ERROR is returned to the caller.  | 
9062  |  | **  | 
9063  |  | ** ^Unless it returns SQLITE_MISUSE,  | 
9064  |  | ** the sqlite3_wal_checkpoint_v2() interface  | 
9065  |  | ** sets the error information that is queried by  | 
9066  |  | ** [sqlite3_errcode()] and [sqlite3_errmsg()].  | 
9067  |  | **  | 
9068  |  | ** ^The [PRAGMA wal_checkpoint] command can be used to invoke this interface  | 
9069  |  | ** from SQL.  | 
9070  |  | */  | 
9071  |  | SQLITE_API int sqlite3_wal_checkpoint_v2(  | 
9072  |  |   sqlite3 *db,                    /* Database handle */  | 
9073  |  |   const char *zDb,                /* Name of attached database (or NULL) */  | 
9074  |  |   int eMode,                      /* SQLITE_CHECKPOINT_* value */  | 
9075  |  |   int *pnLog,                     /* OUT: Size of WAL log in frames */  | 
9076  |  |   int *pnCkpt                     /* OUT: Total number of frames checkpointed */  | 
9077  |  | );  | 
9078  |  |  | 
9079  |  | /*  | 
9080  |  | ** CAPI3REF: Checkpoint Mode Values  | 
9081  |  | ** KEYWORDS: {checkpoint mode} | 
9082  |  | **  | 
9083  |  | ** These constants define all valid values for the "checkpoint mode" passed  | 
9084  |  | ** as the third parameter to the [sqlite3_wal_checkpoint_v2()] interface.  | 
9085  |  | ** See the [sqlite3_wal_checkpoint_v2()] documentation for details on the  | 
9086  |  | ** meaning of each of these checkpoint modes.  | 
9087  |  | */  | 
9088  |  | #define SQLITE_CHECKPOINT_PASSIVE  0  /* Do as much as possible w/o blocking */  | 
9089  |  | #define SQLITE_CHECKPOINT_FULL     1  /* Wait for writers, then checkpoint */  | 
9090  |  | #define SQLITE_CHECKPOINT_RESTART  2  /* Like FULL but wait for for readers */  | 
9091  |  | #define SQLITE_CHECKPOINT_TRUNCATE 3  /* Like RESTART but also truncate WAL */  | 
9092  |  |  | 
9093  |  | /*  | 
9094  |  | ** CAPI3REF: Virtual Table Interface Configuration  | 
9095  |  | **  | 
9096  |  | ** This function may be called by either the [xConnect] or [xCreate] method  | 
9097  |  | ** of a [virtual table] implementation to configure  | 
9098  |  | ** various facets of the virtual table interface.  | 
9099  |  | **  | 
9100  |  | ** If this interface is invoked outside the context of an xConnect or  | 
9101  |  | ** xCreate virtual table method then the behavior is undefined.  | 
9102  |  | **  | 
9103  |  | ** In the call sqlite3_vtab_config(D,C,...) the D parameter is the  | 
9104  |  | ** [database connection] in which the virtual table is being created and  | 
9105  |  | ** which is passed in as the first argument to the [xConnect] or [xCreate]  | 
9106  |  | ** method that is invoking sqlite3_vtab_config().  The C parameter is one  | 
9107  |  | ** of the [virtual table configuration options].  The presence and meaning  | 
9108  |  | ** of parameters after C depend on which [virtual table configuration option]  | 
9109  |  | ** is used.  | 
9110  |  | */  | 
9111  |  | SQLITE_API int sqlite3_vtab_config(sqlite3*, int op, ...);  | 
9112  |  |  | 
9113  |  | /*  | 
9114  |  | ** CAPI3REF: Virtual Table Configuration Options  | 
9115  |  | ** KEYWORDS: {virtual table configuration options} | 
9116  |  | ** KEYWORDS: {virtual table configuration option} | 
9117  |  | **  | 
9118  |  | ** These macros define the various options to the  | 
9119  |  | ** [sqlite3_vtab_config()] interface that [virtual table] implementations  | 
9120  |  | ** can use to customize and optimize their behavior.  | 
9121  |  | **  | 
9122  |  | ** <dl>  | 
9123  |  | ** [[SQLITE_VTAB_CONSTRAINT_SUPPORT]]  | 
9124  |  | ** <dt>SQLITE_VTAB_CONSTRAINT_SUPPORT</dt>  | 
9125  |  | ** <dd>Calls of the form  | 
9126  |  | ** [sqlite3_vtab_config](db,SQLITE_VTAB_CONSTRAINT_SUPPORT,X) are supported,  | 
9127  |  | ** where X is an integer.  If X is zero, then the [virtual table] whose  | 
9128  |  | ** [xCreate] or [xConnect] method invoked [sqlite3_vtab_config()] does not  | 
9129  |  | ** support constraints.  In this configuration (which is the default) if  | 
9130  |  | ** a call to the [xUpdate] method returns [SQLITE_CONSTRAINT], then the entire  | 
9131  |  | ** statement is rolled back as if [ON CONFLICT | OR ABORT] had been  | 
9132  |  | ** specified as part of the users SQL statement, regardless of the actual  | 
9133  |  | ** ON CONFLICT mode specified.  | 
9134  |  | **  | 
9135  |  | ** If X is non-zero, then the virtual table implementation guarantees  | 
9136  |  | ** that if [xUpdate] returns [SQLITE_CONSTRAINT], it will do so before  | 
9137  |  | ** any modifications to internal or persistent data structures have been made.  | 
9138  |  | ** If the [ON CONFLICT] mode is ABORT, FAIL, IGNORE or ROLLBACK, SQLite  | 
9139  |  | ** is able to roll back a statement or database transaction, and abandon  | 
9140  |  | ** or continue processing the current SQL statement as appropriate.  | 
9141  |  | ** If the ON CONFLICT mode is REPLACE and the [xUpdate] method returns  | 
9142  |  | ** [SQLITE_CONSTRAINT], SQLite handles this as if the ON CONFLICT mode  | 
9143  |  | ** had been ABORT.  | 
9144  |  | **  | 
9145  |  | ** Virtual table implementations that are required to handle OR REPLACE  | 
9146  |  | ** must do so within the [xUpdate] method. If a call to the  | 
9147  |  | ** [sqlite3_vtab_on_conflict()] function indicates that the current ON  | 
9148  |  | ** CONFLICT policy is REPLACE, the virtual table implementation should  | 
9149  |  | ** silently replace the appropriate rows within the xUpdate callback and  | 
9150  |  | ** return SQLITE_OK. Or, if this is not possible, it may return  | 
9151  |  | ** SQLITE_CONSTRAINT, in which case SQLite falls back to OR ABORT  | 
9152  |  | ** constraint handling.  | 
9153  |  | ** </dd>  | 
9154  |  | **  | 
9155  |  | ** [[SQLITE_VTAB_DIRECTONLY]]<dt>SQLITE_VTAB_DIRECTONLY</dt>  | 
9156  |  | ** <dd>Calls of the form  | 
9157  |  | ** [sqlite3_vtab_config](db,SQLITE_VTAB_DIRECTONLY) from within the  | 
9158  |  | ** the [xConnect] or [xCreate] methods of a [virtual table] implmentation  | 
9159  |  | ** prohibits that virtual table from being used from within triggers and  | 
9160  |  | ** views.  | 
9161  |  | ** </dd>  | 
9162  |  | **  | 
9163  |  | ** [[SQLITE_VTAB_INNOCUOUS]]<dt>SQLITE_VTAB_INNOCUOUS</dt>  | 
9164  |  | ** <dd>Calls of the form  | 
9165  |  | ** [sqlite3_vtab_config](db,SQLITE_VTAB_INNOCUOUS) from within the  | 
9166  |  | ** the [xConnect] or [xCreate] methods of a [virtual table] implmentation  | 
9167  |  | ** identify that virtual table as being safe to use from within triggers  | 
9168  |  | ** and views.  Conceptually, the SQLITE_VTAB_INNOCUOUS tag means that the  | 
9169  |  | ** virtual table can do no serious harm even if it is controlled by a  | 
9170  |  | ** malicious hacker.  Developers should avoid setting the SQLITE_VTAB_INNOCUOUS  | 
9171  |  | ** flag unless absolutely necessary.  | 
9172  |  | ** </dd>  | 
9173  |  | ** </dl>  | 
9174  |  | */  | 
9175  |  | #define SQLITE_VTAB_CONSTRAINT_SUPPORT 1  | 
9176  |  | #define SQLITE_VTAB_INNOCUOUS          2  | 
9177  |  | #define SQLITE_VTAB_DIRECTONLY         3  | 
9178  |  |  | 
9179  |  | /*  | 
9180  |  | ** CAPI3REF: Determine The Virtual Table Conflict Policy  | 
9181  |  | **  | 
9182  |  | ** This function may only be called from within a call to the [xUpdate] method  | 
9183  |  | ** of a [virtual table] implementation for an INSERT or UPDATE operation. ^The  | 
9184  |  | ** value returned is one of [SQLITE_ROLLBACK], [SQLITE_IGNORE], [SQLITE_FAIL],  | 
9185  |  | ** [SQLITE_ABORT], or [SQLITE_REPLACE], according to the [ON CONFLICT] mode  | 
9186  |  | ** of the SQL statement that triggered the call to the [xUpdate] method of the  | 
9187  |  | ** [virtual table].  | 
9188  |  | */  | 
9189  |  | SQLITE_API int sqlite3_vtab_on_conflict(sqlite3 *);  | 
9190  |  |  | 
9191  |  | /*  | 
9192  |  | ** CAPI3REF: Determine If Virtual Table Column Access Is For UPDATE  | 
9193  |  | **  | 
9194  |  | ** If the sqlite3_vtab_nochange(X) routine is called within the [xColumn]  | 
9195  |  | ** method of a [virtual table], then it returns true if and only if the  | 
9196  |  | ** column is being fetched as part of an UPDATE operation during which the  | 
9197  |  | ** column value will not change.  Applications might use this to substitute  | 
9198  |  | ** a return value that is less expensive to compute and that the corresponding  | 
9199  |  | ** [xUpdate] method understands as a "no-change" value.  | 
9200  |  | **  | 
9201  |  | ** If the [xColumn] method calls sqlite3_vtab_nochange() and finds that  | 
9202  |  | ** the column is not changed by the UPDATE statement, then the xColumn  | 
9203  |  | ** method can optionally return without setting a result, without calling  | 
9204  |  | ** any of the [sqlite3_result_int|sqlite3_result_xxxxx() interfaces].  | 
9205  |  | ** In that case, [sqlite3_value_nochange(X)] will return true for the  | 
9206  |  | ** same column in the [xUpdate] method.  | 
9207  |  | */  | 
9208  |  | SQLITE_API int sqlite3_vtab_nochange(sqlite3_context*);  | 
9209  |  |  | 
9210  |  | /*  | 
9211  |  | ** CAPI3REF: Determine The Collation For a Virtual Table Constraint  | 
9212  |  | **  | 
9213  |  | ** This function may only be called from within a call to the [xBestIndex]  | 
9214  |  | ** method of a [virtual table].  | 
9215  |  | **  | 
9216  |  | ** The first argument must be the sqlite3_index_info object that is the  | 
9217  |  | ** first parameter to the xBestIndex() method. The second argument must be  | 
9218  |  | ** an index into the aConstraint[] array belonging to the sqlite3_index_info  | 
9219  |  | ** structure passed to xBestIndex. This function returns a pointer to a buffer  | 
9220  |  | ** containing the name of the collation sequence for the corresponding  | 
9221  |  | ** constraint.  | 
9222  |  | */  | 
9223  |  | SQLITE_API SQLITE_EXPERIMENTAL const char *sqlite3_vtab_collation(sqlite3_index_info*,int);  | 
9224  |  |  | 
9225  |  | /*  | 
9226  |  | ** CAPI3REF: Conflict resolution modes  | 
9227  |  | ** KEYWORDS: {conflict resolution mode} | 
9228  |  | **  | 
9229  |  | ** These constants are returned by [sqlite3_vtab_on_conflict()] to  | 
9230  |  | ** inform a [virtual table] implementation what the [ON CONFLICT] mode  | 
9231  |  | ** is for the SQL statement being evaluated.  | 
9232  |  | **  | 
9233  |  | ** Note that the [SQLITE_IGNORE] constant is also used as a potential  | 
9234  |  | ** return value from the [sqlite3_set_authorizer()] callback and that  | 
9235  |  | ** [SQLITE_ABORT] is also a [result code].  | 
9236  |  | */  | 
9237  |  | #define SQLITE_ROLLBACK 1  | 
9238  |  | /* #define SQLITE_IGNORE 2 // Also used by sqlite3_authorizer() callback */  | 
9239  |  | #define SQLITE_FAIL     3  | 
9240  |  | /* #define SQLITE_ABORT 4  // Also an error code */  | 
9241  |  | #define SQLITE_REPLACE  5  | 
9242  |  |  | 
9243  |  | /*  | 
9244  |  | ** CAPI3REF: Prepared Statement Scan Status Opcodes  | 
9245  |  | ** KEYWORDS: {scanstatus options} | 
9246  |  | **  | 
9247  |  | ** The following constants can be used for the T parameter to the  | 
9248  |  | ** [sqlite3_stmt_scanstatus(S,X,T,V)] interface.  Each constant designates a  | 
9249  |  | ** different metric for sqlite3_stmt_scanstatus() to return.  | 
9250  |  | **  | 
9251  |  | ** When the value returned to V is a string, space to hold that string is  | 
9252  |  | ** managed by the prepared statement S and will be automatically freed when  | 
9253  |  | ** S is finalized.  | 
9254  |  | **  | 
9255  |  | ** <dl>  | 
9256  |  | ** [[SQLITE_SCANSTAT_NLOOP]] <dt>SQLITE_SCANSTAT_NLOOP</dt>  | 
9257  |  | ** <dd>^The [sqlite3_int64] variable pointed to by the V parameter will be  | 
9258  |  | ** set to the total number of times that the X-th loop has run.</dd>  | 
9259  |  | **  | 
9260  |  | ** [[SQLITE_SCANSTAT_NVISIT]] <dt>SQLITE_SCANSTAT_NVISIT</dt>  | 
9261  |  | ** <dd>^The [sqlite3_int64] variable pointed to by the V parameter will be set  | 
9262  |  | ** to the total number of rows examined by all iterations of the X-th loop.</dd>  | 
9263  |  | **  | 
9264  |  | ** [[SQLITE_SCANSTAT_EST]] <dt>SQLITE_SCANSTAT_EST</dt>  | 
9265  |  | ** <dd>^The "double" variable pointed to by the V parameter will be set to the  | 
9266  |  | ** query planner's estimate for the average number of rows output from each  | 
9267  |  | ** iteration of the X-th loop.  If the query planner's estimates was accurate,  | 
9268  |  | ** then this value will approximate the quotient NVISIT/NLOOP and the  | 
9269  |  | ** product of this value for all prior loops with the same SELECTID will  | 
9270  |  | ** be the NLOOP value for the current loop.  | 
9271  |  | **  | 
9272  |  | ** [[SQLITE_SCANSTAT_NAME]] <dt>SQLITE_SCANSTAT_NAME</dt>  | 
9273  |  | ** <dd>^The "const char *" variable pointed to by the V parameter will be set  | 
9274  |  | ** to a zero-terminated UTF-8 string containing the name of the index or table  | 
9275  |  | ** used for the X-th loop.  | 
9276  |  | **  | 
9277  |  | ** [[SQLITE_SCANSTAT_EXPLAIN]] <dt>SQLITE_SCANSTAT_EXPLAIN</dt>  | 
9278  |  | ** <dd>^The "const char *" variable pointed to by the V parameter will be set  | 
9279  |  | ** to a zero-terminated UTF-8 string containing the [EXPLAIN QUERY PLAN]  | 
9280  |  | ** description for the X-th loop.  | 
9281  |  | **  | 
9282  |  | ** [[SQLITE_SCANSTAT_SELECTID]] <dt>SQLITE_SCANSTAT_SELECT</dt>  | 
9283  |  | ** <dd>^The "int" variable pointed to by the V parameter will be set to the  | 
9284  |  | ** "select-id" for the X-th loop.  The select-id identifies which query or  | 
9285  |  | ** subquery the loop is part of.  The main query has a select-id of zero.  | 
9286  |  | ** The select-id is the same value as is output in the first column  | 
9287  |  | ** of an [EXPLAIN QUERY PLAN] query.  | 
9288  |  | ** </dl>  | 
9289  |  | */  | 
9290  |  | #define SQLITE_SCANSTAT_NLOOP    0  | 
9291  |  | #define SQLITE_SCANSTAT_NVISIT   1  | 
9292  |  | #define SQLITE_SCANSTAT_EST      2  | 
9293  |  | #define SQLITE_SCANSTAT_NAME     3  | 
9294  |  | #define SQLITE_SCANSTAT_EXPLAIN  4  | 
9295  |  | #define SQLITE_SCANSTAT_SELECTID 5  | 
9296  |  |  | 
9297  |  | /*  | 
9298  |  | ** CAPI3REF: Prepared Statement Scan Status  | 
9299  |  | ** METHOD: sqlite3_stmt  | 
9300  |  | **  | 
9301  |  | ** This interface returns information about the predicted and measured  | 
9302  |  | ** performance for pStmt.  Advanced applications can use this  | 
9303  |  | ** interface to compare the predicted and the measured performance and  | 
9304  |  | ** issue warnings and/or rerun [ANALYZE] if discrepancies are found.  | 
9305  |  | **  | 
9306  |  | ** Since this interface is expected to be rarely used, it is only  | 
9307  |  | ** available if SQLite is compiled using the [SQLITE_ENABLE_STMT_SCANSTATUS]  | 
9308  |  | ** compile-time option.  | 
9309  |  | **  | 
9310  |  | ** The "iScanStatusOp" parameter determines which status information to return.  | 
9311  |  | ** The "iScanStatusOp" must be one of the [scanstatus options] or the behavior  | 
9312  |  | ** of this interface is undefined.  | 
9313  |  | ** ^The requested measurement is written into a variable pointed to by  | 
9314  |  | ** the "pOut" parameter.  | 
9315  |  | ** Parameter "idx" identifies the specific loop to retrieve statistics for.  | 
9316  |  | ** Loops are numbered starting from zero. ^If idx is out of range - less than  | 
9317  |  | ** zero or greater than or equal to the total number of loops used to implement  | 
9318  |  | ** the statement - a non-zero value is returned and the variable that pOut  | 
9319  |  | ** points to is unchanged.  | 
9320  |  | **  | 
9321  |  | ** ^Statistics might not be available for all loops in all statements. ^In cases  | 
9322  |  | ** where there exist loops with no available statistics, this function behaves  | 
9323  |  | ** as if the loop did not exist - it returns non-zero and leave the variable  | 
9324  |  | ** that pOut points to unchanged.  | 
9325  |  | **  | 
9326  |  | ** See also: [sqlite3_stmt_scanstatus_reset()]  | 
9327  |  | */  | 
9328  |  | SQLITE_API int sqlite3_stmt_scanstatus(  | 
9329  |  |   sqlite3_stmt *pStmt,      /* Prepared statement for which info desired */  | 
9330  |  |   int idx,                  /* Index of loop to report on */  | 
9331  |  |   int iScanStatusOp,        /* Information desired.  SQLITE_SCANSTAT_* */  | 
9332  |  |   void *pOut                /* Result written here */  | 
9333  |  | );  | 
9334  |  |  | 
9335  |  | /*  | 
9336  |  | ** CAPI3REF: Zero Scan-Status Counters  | 
9337  |  | ** METHOD: sqlite3_stmt  | 
9338  |  | **  | 
9339  |  | ** ^Zero all [sqlite3_stmt_scanstatus()] related event counters.  | 
9340  |  | **  | 
9341  |  | ** This API is only available if the library is built with pre-processor  | 
9342  |  | ** symbol [SQLITE_ENABLE_STMT_SCANSTATUS] defined.  | 
9343  |  | */  | 
9344  |  | SQLITE_API void sqlite3_stmt_scanstatus_reset(sqlite3_stmt*);  | 
9345  |  |  | 
9346  |  | /*  | 
9347  |  | ** CAPI3REF: Flush caches to disk mid-transaction  | 
9348  |  | **  | 
9349  |  | ** ^If a write-transaction is open on [database connection] D when the  | 
9350  |  | ** [sqlite3_db_cacheflush(D)] interface invoked, any dirty  | 
9351  |  | ** pages in the pager-cache that are not currently in use are written out  | 
9352  |  | ** to disk. A dirty page may be in use if a database cursor created by an  | 
9353  |  | ** active SQL statement is reading from it, or if it is page 1 of a database  | 
9354  |  | ** file (page 1 is always "in use").  ^The [sqlite3_db_cacheflush(D)]  | 
9355  |  | ** interface flushes caches for all schemas - "main", "temp", and  | 
9356  |  | ** any [attached] databases.  | 
9357  |  | **  | 
9358  |  | ** ^If this function needs to obtain extra database locks before dirty pages  | 
9359  |  | ** can be flushed to disk, it does so. ^If those locks cannot be obtained  | 
9360  |  | ** immediately and there is a busy-handler callback configured, it is invoked  | 
9361  |  | ** in the usual manner. ^If the required lock still cannot be obtained, then  | 
9362  |  | ** the database is skipped and an attempt made to flush any dirty pages  | 
9363  |  | ** belonging to the next (if any) database. ^If any databases are skipped  | 
9364  |  | ** because locks cannot be obtained, but no other error occurs, this  | 
9365  |  | ** function returns SQLITE_BUSY.  | 
9366  |  | **  | 
9367  |  | ** ^If any other error occurs while flushing dirty pages to disk (for  | 
9368  |  | ** example an IO error or out-of-memory condition), then processing is  | 
9369  |  | ** abandoned and an SQLite [error code] is returned to the caller immediately.  | 
9370  |  | **  | 
9371  |  | ** ^Otherwise, if no error occurs, [sqlite3_db_cacheflush()] returns SQLITE_OK.  | 
9372  |  | **  | 
9373  |  | ** ^This function does not set the database handle error code or message  | 
9374  |  | ** returned by the [sqlite3_errcode()] and [sqlite3_errmsg()] functions.  | 
9375  |  | */  | 
9376  |  | SQLITE_API int sqlite3_db_cacheflush(sqlite3*);  | 
9377  |  |  | 
9378  |  | /*  | 
9379  |  | ** CAPI3REF: The pre-update hook.  | 
9380  |  | **  | 
9381  |  | ** ^These interfaces are only available if SQLite is compiled using the  | 
9382  |  | ** [SQLITE_ENABLE_PREUPDATE_HOOK] compile-time option.  | 
9383  |  | **  | 
9384  |  | ** ^The [sqlite3_preupdate_hook()] interface registers a callback function  | 
9385  |  | ** that is invoked prior to each [INSERT], [UPDATE], and [DELETE] operation  | 
9386  |  | ** on a database table.  | 
9387  |  | ** ^At most one preupdate hook may be registered at a time on a single  | 
9388  |  | ** [database connection]; each call to [sqlite3_preupdate_hook()] overrides  | 
9389  |  | ** the previous setting.  | 
9390  |  | ** ^The preupdate hook is disabled by invoking [sqlite3_preupdate_hook()]  | 
9391  |  | ** with a NULL pointer as the second parameter.  | 
9392  |  | ** ^The third parameter to [sqlite3_preupdate_hook()] is passed through as  | 
9393  |  | ** the first parameter to callbacks.  | 
9394  |  | **  | 
9395  |  | ** ^The preupdate hook only fires for changes to real database tables; the  | 
9396  |  | ** preupdate hook is not invoked for changes to [virtual tables] or to  | 
9397  |  | ** system tables like sqlite_sequence or sqlite_stat1.  | 
9398  |  | **  | 
9399  |  | ** ^The second parameter to the preupdate callback is a pointer to  | 
9400  |  | ** the [database connection] that registered the preupdate hook.  | 
9401  |  | ** ^The third parameter to the preupdate callback is one of the constants  | 
9402  |  | ** [SQLITE_INSERT], [SQLITE_DELETE], or [SQLITE_UPDATE] to identify the  | 
9403  |  | ** kind of update operation that is about to occur.  | 
9404  |  | ** ^(The fourth parameter to the preupdate callback is the name of the  | 
9405  |  | ** database within the database connection that is being modified.  This  | 
9406  |  | ** will be "main" for the main database or "temp" for TEMP tables or  | 
9407  |  | ** the name given after the AS keyword in the [ATTACH] statement for attached  | 
9408  |  | ** databases.)^  | 
9409  |  | ** ^The fifth parameter to the preupdate callback is the name of the  | 
9410  |  | ** table that is being modified.  | 
9411  |  | **  | 
9412  |  | ** For an UPDATE or DELETE operation on a [rowid table], the sixth  | 
9413  |  | ** parameter passed to the preupdate callback is the initial [rowid] of the  | 
9414  |  | ** row being modified or deleted. For an INSERT operation on a rowid table,  | 
9415  |  | ** or any operation on a WITHOUT ROWID table, the value of the sixth  | 
9416  |  | ** parameter is undefined. For an INSERT or UPDATE on a rowid table the  | 
9417  |  | ** seventh parameter is the final rowid value of the row being inserted  | 
9418  |  | ** or updated. The value of the seventh parameter passed to the callback  | 
9419  |  | ** function is not defined for operations on WITHOUT ROWID tables, or for  | 
9420  |  | ** INSERT operations on rowid tables.  | 
9421  |  | **  | 
9422  |  | ** The [sqlite3_preupdate_old()], [sqlite3_preupdate_new()],  | 
9423  |  | ** [sqlite3_preupdate_count()], and [sqlite3_preupdate_depth()] interfaces  | 
9424  |  | ** provide additional information about a preupdate event. These routines  | 
9425  |  | ** may only be called from within a preupdate callback.  Invoking any of  | 
9426  |  | ** these routines from outside of a preupdate callback or with a  | 
9427  |  | ** [database connection] pointer that is different from the one supplied  | 
9428  |  | ** to the preupdate callback results in undefined and probably undesirable  | 
9429  |  | ** behavior.  | 
9430  |  | **  | 
9431  |  | ** ^The [sqlite3_preupdate_count(D)] interface returns the number of columns  | 
9432  |  | ** in the row that is being inserted, updated, or deleted.  | 
9433  |  | **  | 
9434  |  | ** ^The [sqlite3_preupdate_old(D,N,P)] interface writes into P a pointer to  | 
9435  |  | ** a [protected sqlite3_value] that contains the value of the Nth column of  | 
9436  |  | ** the table row before it is updated.  The N parameter must be between 0  | 
9437  |  | ** and one less than the number of columns or the behavior will be  | 
9438  |  | ** undefined. This must only be used within SQLITE_UPDATE and SQLITE_DELETE  | 
9439  |  | ** preupdate callbacks; if it is used by an SQLITE_INSERT callback then the  | 
9440  |  | ** behavior is undefined.  The [sqlite3_value] that P points to  | 
9441  |  | ** will be destroyed when the preupdate callback returns.  | 
9442  |  | **  | 
9443  |  | ** ^The [sqlite3_preupdate_new(D,N,P)] interface writes into P a pointer to  | 
9444  |  | ** a [protected sqlite3_value] that contains the value of the Nth column of  | 
9445  |  | ** the table row after it is updated.  The N parameter must be between 0  | 
9446  |  | ** and one less than the number of columns or the behavior will be  | 
9447  |  | ** undefined. This must only be used within SQLITE_INSERT and SQLITE_UPDATE  | 
9448  |  | ** preupdate callbacks; if it is used by an SQLITE_DELETE callback then the  | 
9449  |  | ** behavior is undefined.  The [sqlite3_value] that P points to  | 
9450  |  | ** will be destroyed when the preupdate callback returns.  | 
9451  |  | **  | 
9452  |  | ** ^The [sqlite3_preupdate_depth(D)] interface returns 0 if the preupdate  | 
9453  |  | ** callback was invoked as a result of a direct insert, update, or delete  | 
9454  |  | ** operation; or 1 for inserts, updates, or deletes invoked by top-level  | 
9455  |  | ** triggers; or 2 for changes resulting from triggers called by top-level  | 
9456  |  | ** triggers; and so forth.  | 
9457  |  | **  | 
9458  |  | ** See also:  [sqlite3_update_hook()]  | 
9459  |  | */  | 
9460  |  | #if defined(SQLITE_ENABLE_PREUPDATE_HOOK)  | 
9461  |  | SQLITE_API void *sqlite3_preupdate_hook(  | 
9462  |  |   sqlite3 *db,  | 
9463  |  |   void(*xPreUpdate)(  | 
9464  |  |     void *pCtx,                   /* Copy of third arg to preupdate_hook() */  | 
9465  |  |     sqlite3 *db,                  /* Database handle */  | 
9466  |  |     int op,                       /* SQLITE_UPDATE, DELETE or INSERT */  | 
9467  |  |     char const *zDb,              /* Database name */  | 
9468  |  |     char const *zName,            /* Table name */  | 
9469  |  |     sqlite3_int64 iKey1,          /* Rowid of row about to be deleted/updated */  | 
9470  |  |     sqlite3_int64 iKey2           /* New rowid value (for a rowid UPDATE) */  | 
9471  |  |   ),  | 
9472  |  |   void*  | 
9473  |  | );  | 
9474  |  | SQLITE_API int sqlite3_preupdate_old(sqlite3 *, int, sqlite3_value **);  | 
9475  |  | SQLITE_API int sqlite3_preupdate_count(sqlite3 *);  | 
9476  |  | SQLITE_API int sqlite3_preupdate_depth(sqlite3 *);  | 
9477  |  | SQLITE_API int sqlite3_preupdate_new(sqlite3 *, int, sqlite3_value **);  | 
9478  |  | #endif  | 
9479  |  |  | 
9480  |  | /*  | 
9481  |  | ** CAPI3REF: Low-level system error code  | 
9482  |  | **  | 
9483  |  | ** ^Attempt to return the underlying operating system error code or error  | 
9484  |  | ** number that caused the most recent I/O error or failure to open a file.  | 
9485  |  | ** The return value is OS-dependent.  For example, on unix systems, after  | 
9486  |  | ** [sqlite3_open_v2()] returns [SQLITE_CANTOPEN], this interface could be  | 
9487  |  | ** called to get back the underlying "errno" that caused the problem, such  | 
9488  |  | ** as ENOSPC, EAUTH, EISDIR, and so forth.  | 
9489  |  | */  | 
9490  |  | SQLITE_API int sqlite3_system_errno(sqlite3*);  | 
9491  |  |  | 
9492  |  | /*  | 
9493  |  | ** CAPI3REF: Database Snapshot  | 
9494  |  | ** KEYWORDS: {snapshot} {sqlite3_snapshot} | 
9495  |  | **  | 
9496  |  | ** An instance of the snapshot object records the state of a [WAL mode]  | 
9497  |  | ** database for some specific point in history.  | 
9498  |  | **  | 
9499  |  | ** In [WAL mode], multiple [database connections] that are open on the  | 
9500  |  | ** same database file can each be reading a different historical version  | 
9501  |  | ** of the database file.  When a [database connection] begins a read  | 
9502  |  | ** transaction, that connection sees an unchanging copy of the database  | 
9503  |  | ** as it existed for the point in time when the transaction first started.  | 
9504  |  | ** Subsequent changes to the database from other connections are not seen  | 
9505  |  | ** by the reader until a new read transaction is started.  | 
9506  |  | **  | 
9507  |  | ** The sqlite3_snapshot object records state information about an historical  | 
9508  |  | ** version of the database file so that it is possible to later open a new read  | 
9509  |  | ** transaction that sees that historical version of the database rather than  | 
9510  |  | ** the most recent version.  | 
9511  |  | */  | 
9512  |  | typedef struct sqlite3_snapshot { | 
9513  |  |   unsigned char hidden[48];  | 
9514  |  | } sqlite3_snapshot;  | 
9515  |  |  | 
9516  |  | /*  | 
9517  |  | ** CAPI3REF: Record A Database Snapshot  | 
9518  |  | ** CONSTRUCTOR: sqlite3_snapshot  | 
9519  |  | **  | 
9520  |  | ** ^The [sqlite3_snapshot_get(D,S,P)] interface attempts to make a  | 
9521  |  | ** new [sqlite3_snapshot] object that records the current state of  | 
9522  |  | ** schema S in database connection D.  ^On success, the  | 
9523  |  | ** [sqlite3_snapshot_get(D,S,P)] interface writes a pointer to the newly  | 
9524  |  | ** created [sqlite3_snapshot] object into *P and returns SQLITE_OK.  | 
9525  |  | ** If there is not already a read-transaction open on schema S when  | 
9526  |  | ** this function is called, one is opened automatically.  | 
9527  |  | **  | 
9528  |  | ** The following must be true for this function to succeed. If any of  | 
9529  |  | ** the following statements are false when sqlite3_snapshot_get() is  | 
9530  |  | ** called, SQLITE_ERROR is returned. The final value of *P is undefined  | 
9531  |  | ** in this case.  | 
9532  |  | **  | 
9533  |  | ** <ul>  | 
9534  |  | **   <li> The database handle must not be in [autocommit mode].  | 
9535  |  | **  | 
9536  |  | **   <li> Schema S of [database connection] D must be a [WAL mode] database.  | 
9537  |  | **  | 
9538  |  | **   <li> There must not be a write transaction open on schema S of database  | 
9539  |  | **        connection D.  | 
9540  |  | **  | 
9541  |  | **   <li> One or more transactions must have been written to the current wal  | 
9542  |  | **        file since it was created on disk (by any connection). This means  | 
9543  |  | **        that a snapshot cannot be taken on a wal mode database with no wal  | 
9544  |  | **        file immediately after it is first opened. At least one transaction  | 
9545  |  | **        must be written to it first.  | 
9546  |  | ** </ul>  | 
9547  |  | **  | 
9548  |  | ** This function may also return SQLITE_NOMEM.  If it is called with the  | 
9549  |  | ** database handle in autocommit mode but fails for some other reason,  | 
9550  |  | ** whether or not a read transaction is opened on schema S is undefined.  | 
9551  |  | **  | 
9552  |  | ** The [sqlite3_snapshot] object returned from a successful call to  | 
9553  |  | ** [sqlite3_snapshot_get()] must be freed using [sqlite3_snapshot_free()]  | 
9554  |  | ** to avoid a memory leak.  | 
9555  |  | **  | 
9556  |  | ** The [sqlite3_snapshot_get()] interface is only available when the  | 
9557  |  | ** [SQLITE_ENABLE_SNAPSHOT] compile-time option is used.  | 
9558  |  | */  | 
9559  |  | SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_snapshot_get(  | 
9560  |  |   sqlite3 *db,  | 
9561  |  |   const char *zSchema,  | 
9562  |  |   sqlite3_snapshot **ppSnapshot  | 
9563  |  | );  | 
9564  |  |  | 
9565  |  | /*  | 
9566  |  | ** CAPI3REF: Start a read transaction on an historical snapshot  | 
9567  |  | ** METHOD: sqlite3_snapshot  | 
9568  |  | **  | 
9569  |  | ** ^The [sqlite3_snapshot_open(D,S,P)] interface either starts a new read  | 
9570  |  | ** transaction or upgrades an existing one for schema S of  | 
9571  |  | ** [database connection] D such that the read transaction refers to  | 
9572  |  | ** historical [snapshot] P, rather than the most recent change to the  | 
9573  |  | ** database. ^The [sqlite3_snapshot_open()] interface returns SQLITE_OK  | 
9574  |  | ** on success or an appropriate [error code] if it fails.  | 
9575  |  | **  | 
9576  |  | ** ^In order to succeed, the database connection must not be in  | 
9577  |  | ** [autocommit mode] when [sqlite3_snapshot_open(D,S,P)] is called. If there  | 
9578  |  | ** is already a read transaction open on schema S, then the database handle  | 
9579  |  | ** must have no active statements (SELECT statements that have been passed  | 
9580  |  | ** to sqlite3_step() but not sqlite3_reset() or sqlite3_finalize()).  | 
9581  |  | ** SQLITE_ERROR is returned if either of these conditions is violated, or  | 
9582  |  | ** if schema S does not exist, or if the snapshot object is invalid.  | 
9583  |  | **  | 
9584  |  | ** ^A call to sqlite3_snapshot_open() will fail to open if the specified  | 
9585  |  | ** snapshot has been overwritten by a [checkpoint]. In this case  | 
9586  |  | ** SQLITE_ERROR_SNAPSHOT is returned.  | 
9587  |  | **  | 
9588  |  | ** If there is already a read transaction open when this function is  | 
9589  |  | ** invoked, then the same read transaction remains open (on the same  | 
9590  |  | ** database snapshot) if SQLITE_ERROR, SQLITE_BUSY or SQLITE_ERROR_SNAPSHOT  | 
9591  |  | ** is returned. If another error code - for example SQLITE_PROTOCOL or an  | 
9592  |  | ** SQLITE_IOERR error code - is returned, then the final state of the  | 
9593  |  | ** read transaction is undefined. If SQLITE_OK is returned, then the  | 
9594  |  | ** read transaction is now open on database snapshot P.  | 
9595  |  | **  | 
9596  |  | ** ^(A call to [sqlite3_snapshot_open(D,S,P)] will fail if the  | 
9597  |  | ** database connection D does not know that the database file for  | 
9598  |  | ** schema S is in [WAL mode].  A database connection might not know  | 
9599  |  | ** that the database file is in [WAL mode] if there has been no prior  | 
9600  |  | ** I/O on that database connection, or if the database entered [WAL mode]  | 
9601  |  | ** after the most recent I/O on the database connection.)^  | 
9602  |  | ** (Hint: Run "[PRAGMA application_id]" against a newly opened  | 
9603  |  | ** database connection in order to make it ready to use snapshots.)  | 
9604  |  | **  | 
9605  |  | ** The [sqlite3_snapshot_open()] interface is only available when the  | 
9606  |  | ** [SQLITE_ENABLE_SNAPSHOT] compile-time option is used.  | 
9607  |  | */  | 
9608  |  | SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_snapshot_open(  | 
9609  |  |   sqlite3 *db,  | 
9610  |  |   const char *zSchema,  | 
9611  |  |   sqlite3_snapshot *pSnapshot  | 
9612  |  | );  | 
9613  |  |  | 
9614  |  | /*  | 
9615  |  | ** CAPI3REF: Destroy a snapshot  | 
9616  |  | ** DESTRUCTOR: sqlite3_snapshot  | 
9617  |  | **  | 
9618  |  | ** ^The [sqlite3_snapshot_free(P)] interface destroys [sqlite3_snapshot] P.  | 
9619  |  | ** The application must eventually free every [sqlite3_snapshot] object  | 
9620  |  | ** using this routine to avoid a memory leak.  | 
9621  |  | **  | 
9622  |  | ** The [sqlite3_snapshot_free()] interface is only available when the  | 
9623  |  | ** [SQLITE_ENABLE_SNAPSHOT] compile-time option is used.  | 
9624  |  | */  | 
9625  |  | SQLITE_API SQLITE_EXPERIMENTAL void sqlite3_snapshot_free(sqlite3_snapshot*);  | 
9626  |  |  | 
9627  |  | /*  | 
9628  |  | ** CAPI3REF: Compare the ages of two snapshot handles.  | 
9629  |  | ** METHOD: sqlite3_snapshot  | 
9630  |  | **  | 
9631  |  | ** The sqlite3_snapshot_cmp(P1, P2) interface is used to compare the ages  | 
9632  |  | ** of two valid snapshot handles.  | 
9633  |  | **  | 
9634  |  | ** If the two snapshot handles are not associated with the same database  | 
9635  |  | ** file, the result of the comparison is undefined.  | 
9636  |  | **  | 
9637  |  | ** Additionally, the result of the comparison is only valid if both of the  | 
9638  |  | ** snapshot handles were obtained by calling sqlite3_snapshot_get() since the  | 
9639  |  | ** last time the wal file was deleted. The wal file is deleted when the  | 
9640  |  | ** database is changed back to rollback mode or when the number of database  | 
9641  |  | ** clients drops to zero. If either snapshot handle was obtained before the  | 
9642  |  | ** wal file was last deleted, the value returned by this function  | 
9643  |  | ** is undefined.  | 
9644  |  | **  | 
9645  |  | ** Otherwise, this API returns a negative value if P1 refers to an older  | 
9646  |  | ** snapshot than P2, zero if the two handles refer to the same database  | 
9647  |  | ** snapshot, and a positive value if P1 is a newer snapshot than P2.  | 
9648  |  | **  | 
9649  |  | ** This interface is only available if SQLite is compiled with the  | 
9650  |  | ** [SQLITE_ENABLE_SNAPSHOT] option.  | 
9651  |  | */  | 
9652  |  | SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_snapshot_cmp(  | 
9653  |  |   sqlite3_snapshot *p1,  | 
9654  |  |   sqlite3_snapshot *p2  | 
9655  |  | );  | 
9656  |  |  | 
9657  |  | /*  | 
9658  |  | ** CAPI3REF: Recover snapshots from a wal file  | 
9659  |  | ** METHOD: sqlite3_snapshot  | 
9660  |  | **  | 
9661  |  | ** If a [WAL file] remains on disk after all database connections close  | 
9662  |  | ** (either through the use of the [SQLITE_FCNTL_PERSIST_WAL] [file control]  | 
9663  |  | ** or because the last process to have the database opened exited without  | 
9664  |  | ** calling [sqlite3_close()]) and a new connection is subsequently opened  | 
9665  |  | ** on that database and [WAL file], the [sqlite3_snapshot_open()] interface  | 
9666  |  | ** will only be able to open the last transaction added to the WAL file  | 
9667  |  | ** even though the WAL file contains other valid transactions.  | 
9668  |  | **  | 
9669  |  | ** This function attempts to scan the WAL file associated with database zDb  | 
9670  |  | ** of database handle db and make all valid snapshots available to  | 
9671  |  | ** sqlite3_snapshot_open(). It is an error if there is already a read  | 
9672  |  | ** transaction open on the database, or if the database is not a WAL mode  | 
9673  |  | ** database.  | 
9674  |  | **  | 
9675  |  | ** SQLITE_OK is returned if successful, or an SQLite error code otherwise.  | 
9676  |  | **  | 
9677  |  | ** This interface is only available if SQLite is compiled with the  | 
9678  |  | ** [SQLITE_ENABLE_SNAPSHOT] option.  | 
9679  |  | */  | 
9680  |  | SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_snapshot_recover(sqlite3 *db, const char *zDb);  | 
9681  |  |  | 
9682  |  | /*  | 
9683  |  | ** CAPI3REF: Serialize a database  | 
9684  |  | **  | 
9685  |  | ** The sqlite3_serialize(D,S,P,F) interface returns a pointer to memory  | 
9686  |  | ** that is a serialization of the S database on [database connection] D.  | 
9687  |  | ** If P is not a NULL pointer, then the size of the database in bytes  | 
9688  |  | ** is written into *P.  | 
9689  |  | **  | 
9690  |  | ** For an ordinary on-disk database file, the serialization is just a  | 
9691  |  | ** copy of the disk file.  For an in-memory database or a "TEMP" database,  | 
9692  |  | ** the serialization is the same sequence of bytes which would be written  | 
9693  |  | ** to disk if that database where backed up to disk.  | 
9694  |  | **  | 
9695  |  | ** The usual case is that sqlite3_serialize() copies the serialization of  | 
9696  |  | ** the database into memory obtained from [sqlite3_malloc64()] and returns  | 
9697  |  | ** a pointer to that memory.  The caller is responsible for freeing the  | 
9698  |  | ** returned value to avoid a memory leak.  However, if the F argument  | 
9699  |  | ** contains the SQLITE_SERIALIZE_NOCOPY bit, then no memory allocations  | 
9700  |  | ** are made, and the sqlite3_serialize() function will return a pointer  | 
9701  |  | ** to the contiguous memory representation of the database that SQLite  | 
9702  |  | ** is currently using for that database, or NULL if the no such contiguous  | 
9703  |  | ** memory representation of the database exists.  A contiguous memory  | 
9704  |  | ** representation of the database will usually only exist if there has  | 
9705  |  | ** been a prior call to [sqlite3_deserialize(D,S,...)] with the same  | 
9706  |  | ** values of D and S.  | 
9707  |  | ** The size of the database is written into *P even if the  | 
9708  |  | ** SQLITE_SERIALIZE_NOCOPY bit is set but no contiguous copy  | 
9709  |  | ** of the database exists.  | 
9710  |  | **  | 
9711  |  | ** A call to sqlite3_serialize(D,S,P,F) might return NULL even if the  | 
9712  |  | ** SQLITE_SERIALIZE_NOCOPY bit is omitted from argument F if a memory  | 
9713  |  | ** allocation error occurs.  | 
9714  |  | **  | 
9715  |  | ** This interface is only available if SQLite is compiled with the  | 
9716  |  | ** [SQLITE_ENABLE_DESERIALIZE] option.  | 
9717  |  | */  | 
9718  |  | SQLITE_API unsigned char *sqlite3_serialize(  | 
9719  |  |   sqlite3 *db,           /* The database connection */  | 
9720  |  |   const char *zSchema,   /* Which DB to serialize. ex: "main", "temp", ... */  | 
9721  |  |   sqlite3_int64 *piSize, /* Write size of the DB here, if not NULL */  | 
9722  |  |   unsigned int mFlags    /* Zero or more SQLITE_SERIALIZE_* flags */  | 
9723  |  | );  | 
9724  |  |  | 
9725  |  | /*  | 
9726  |  | ** CAPI3REF: Flags for sqlite3_serialize  | 
9727  |  | **  | 
9728  |  | ** Zero or more of the following constants can be OR-ed together for  | 
9729  |  | ** the F argument to [sqlite3_serialize(D,S,P,F)].  | 
9730  |  | **  | 
9731  |  | ** SQLITE_SERIALIZE_NOCOPY means that [sqlite3_serialize()] will return  | 
9732  |  | ** a pointer to contiguous in-memory database that it is currently using,  | 
9733  |  | ** without making a copy of the database.  If SQLite is not currently using  | 
9734  |  | ** a contiguous in-memory database, then this option causes  | 
9735  |  | ** [sqlite3_serialize()] to return a NULL pointer.  SQLite will only be  | 
9736  |  | ** using a contiguous in-memory database if it has been initialized by a  | 
9737  |  | ** prior call to [sqlite3_deserialize()].  | 
9738  |  | */  | 
9739  |  | #define SQLITE_SERIALIZE_NOCOPY 0x001   /* Do no memory allocations */  | 
9740  |  |  | 
9741  |  | /*  | 
9742  |  | ** CAPI3REF: Deserialize a database  | 
9743  |  | **  | 
9744  |  | ** The sqlite3_deserialize(D,S,P,N,M,F) interface causes the  | 
9745  |  | ** [database connection] D to disconnect from database S and then  | 
9746  |  | ** reopen S as an in-memory database based on the serialization contained  | 
9747  |  | ** in P.  The serialized database P is N bytes in size.  M is the size of  | 
9748  |  | ** the buffer P, which might be larger than N.  If M is larger than N, and  | 
9749  |  | ** the SQLITE_DESERIALIZE_READONLY bit is not set in F, then SQLite is  | 
9750  |  | ** permitted to add content to the in-memory database as long as the total  | 
9751  |  | ** size does not exceed M bytes.  | 
9752  |  | **  | 
9753  |  | ** If the SQLITE_DESERIALIZE_FREEONCLOSE bit is set in F, then SQLite will  | 
9754  |  | ** invoke sqlite3_free() on the serialization buffer when the database  | 
9755  |  | ** connection closes.  If the SQLITE_DESERIALIZE_RESIZEABLE bit is set, then  | 
9756  |  | ** SQLite will try to increase the buffer size using sqlite3_realloc64()  | 
9757  |  | ** if writes on the database cause it to grow larger than M bytes.  | 
9758  |  | **  | 
9759  |  | ** The sqlite3_deserialize() interface will fail with SQLITE_BUSY if the  | 
9760  |  | ** database is currently in a read transaction or is involved in a backup  | 
9761  |  | ** operation.  | 
9762  |  | **  | 
9763  |  | ** If sqlite3_deserialize(D,S,P,N,M,F) fails for any reason and if the  | 
9764  |  | ** SQLITE_DESERIALIZE_FREEONCLOSE bit is set in argument F, then  | 
9765  |  | ** [sqlite3_free()] is invoked on argument P prior to returning.  | 
9766  |  | **  | 
9767  |  | ** This interface is only available if SQLite is compiled with the  | 
9768  |  | ** [SQLITE_ENABLE_DESERIALIZE] option.  | 
9769  |  | */  | 
9770  |  | SQLITE_API int sqlite3_deserialize(  | 
9771  |  |   sqlite3 *db,            /* The database connection */  | 
9772  |  |   const char *zSchema,    /* Which DB to reopen with the deserialization */  | 
9773  |  |   unsigned char *pData,   /* The serialized database content */  | 
9774  |  |   sqlite3_int64 szDb,     /* Number bytes in the deserialization */  | 
9775  |  |   sqlite3_int64 szBuf,    /* Total size of buffer pData[] */  | 
9776  |  |   unsigned mFlags         /* Zero or more SQLITE_DESERIALIZE_* flags */  | 
9777  |  | );  | 
9778  |  |  | 
9779  |  | /*  | 
9780  |  | ** CAPI3REF: Flags for sqlite3_deserialize()  | 
9781  |  | **  | 
9782  |  | ** The following are allowed values for 6th argument (the F argument) to  | 
9783  |  | ** the [sqlite3_deserialize(D,S,P,N,M,F)] interface.  | 
9784  |  | **  | 
9785  |  | ** The SQLITE_DESERIALIZE_FREEONCLOSE means that the database serialization  | 
9786  |  | ** in the P argument is held in memory obtained from [sqlite3_malloc64()]  | 
9787  |  | ** and that SQLite should take ownership of this memory and automatically  | 
9788  |  | ** free it when it has finished using it.  Without this flag, the caller  | 
9789  |  | ** is responsible for freeing any dynamically allocated memory.  | 
9790  |  | **  | 
9791  |  | ** The SQLITE_DESERIALIZE_RESIZEABLE flag means that SQLite is allowed to  | 
9792  |  | ** grow the size of the database using calls to [sqlite3_realloc64()].  This  | 
9793  |  | ** flag should only be used if SQLITE_DESERIALIZE_FREEONCLOSE is also used.  | 
9794  |  | ** Without this flag, the deserialized database cannot increase in size beyond  | 
9795  |  | ** the number of bytes specified by the M parameter.  | 
9796  |  | **  | 
9797  |  | ** The SQLITE_DESERIALIZE_READONLY flag means that the deserialized database  | 
9798  |  | ** should be treated as read-only.  | 
9799  |  | */  | 
9800  |  | #define SQLITE_DESERIALIZE_FREEONCLOSE 1 /* Call sqlite3_free() on close */  | 
9801  |  | #define SQLITE_DESERIALIZE_RESIZEABLE  2 /* Resize using sqlite3_realloc64() */  | 
9802  |  | #define SQLITE_DESERIALIZE_READONLY    4 /* Database is read-only */  | 
9803  |  |  | 
9804  |  | /*  | 
9805  |  | ** Undo the hack that converts floating point types to integer for  | 
9806  |  | ** builds on processors without floating point support.  | 
9807  |  | */  | 
9808  |  | #ifdef SQLITE_OMIT_FLOATING_POINT  | 
9809  |  | # undef double  | 
9810  |  | #endif  | 
9811  |  |  | 
9812  |  | #ifdef __cplusplus  | 
9813  |  | }  /* End of the 'extern "C"' block */  | 
9814  |  | #endif  | 
9815  |  | #endif /* SQLITE3_H */  | 
9816  |  |  | 
9817  |  | /******** Begin file sqlite3rtree.h *********/  | 
9818  |  | /*  | 
9819  |  | ** 2010 August 30  | 
9820  |  | **  | 
9821  |  | ** The author disclaims copyright to this source code.  In place of  | 
9822  |  | ** a legal notice, here is a blessing:  | 
9823  |  | **  | 
9824  |  | **    May you do good and not evil.  | 
9825  |  | **    May you find forgiveness for yourself and forgive others.  | 
9826  |  | **    May you share freely, never taking more than you give.  | 
9827  |  | **  | 
9828  |  | *************************************************************************  | 
9829  |  | */  | 
9830  |  |  | 
9831  |  | #ifndef _SQLITE3RTREE_H_  | 
9832  |  | #define _SQLITE3RTREE_H_  | 
9833  |  |  | 
9834  |  |  | 
9835  |  | #ifdef __cplusplus  | 
9836  |  | extern "C" { | 
9837  |  | #endif  | 
9838  |  |  | 
9839  |  | typedef struct sqlite3_rtree_geometry sqlite3_rtree_geometry;  | 
9840  |  | typedef struct sqlite3_rtree_query_info sqlite3_rtree_query_info;  | 
9841  |  |  | 
9842  |  | /* The double-precision datatype used by RTree depends on the  | 
9843  |  | ** SQLITE_RTREE_INT_ONLY compile-time option.  | 
9844  |  | */  | 
9845  |  | #ifdef SQLITE_RTREE_INT_ONLY  | 
9846  |  |   typedef sqlite3_int64 sqlite3_rtree_dbl;  | 
9847  |  | #else  | 
9848  |  |   typedef double sqlite3_rtree_dbl;  | 
9849  |  | #endif  | 
9850  |  |  | 
9851  |  | /*  | 
9852  |  | ** Register a geometry callback named zGeom that can be used as part of an  | 
9853  |  | ** R-Tree geometry query as follows:  | 
9854  |  | **  | 
9855  |  | **   SELECT ... FROM <rtree> WHERE <rtree col> MATCH $zGeom(... params ...)  | 
9856  |  | */  | 
9857  |  | SQLITE_API int sqlite3_rtree_geometry_callback(  | 
9858  |  |   sqlite3 *db,  | 
9859  |  |   const char *zGeom,  | 
9860  |  |   int (*xGeom)(sqlite3_rtree_geometry*, int, sqlite3_rtree_dbl*,int*),  | 
9861  |  |   void *pContext  | 
9862  |  | );  | 
9863  |  |  | 
9864  |  |  | 
9865  |  | /*  | 
9866  |  | ** A pointer to a structure of the following type is passed as the first  | 
9867  |  | ** argument to callbacks registered using rtree_geometry_callback().  | 
9868  |  | */  | 
9869  |  | struct sqlite3_rtree_geometry { | 
9870  |  |   void *pContext;                 /* Copy of pContext passed to s_r_g_c() */  | 
9871  |  |   int nParam;                     /* Size of array aParam[] */  | 
9872  |  |   sqlite3_rtree_dbl *aParam;      /* Parameters passed to SQL geom function */  | 
9873  |  |   void *pUser;                    /* Callback implementation user data */  | 
9874  |  |   void (*xDelUser)(void *);       /* Called by SQLite to clean up pUser */  | 
9875  |  | };  | 
9876  |  |  | 
9877  |  | /*  | 
9878  |  | ** Register a 2nd-generation geometry callback named zScore that can be  | 
9879  |  | ** used as part of an R-Tree geometry query as follows:  | 
9880  |  | **  | 
9881  |  | **   SELECT ... FROM <rtree> WHERE <rtree col> MATCH $zQueryFunc(... params ...)  | 
9882  |  | */  | 
9883  |  | SQLITE_API int sqlite3_rtree_query_callback(  | 
9884  |  |   sqlite3 *db,  | 
9885  |  |   const char *zQueryFunc,  | 
9886  |  |   int (*xQueryFunc)(sqlite3_rtree_query_info*),  | 
9887  |  |   void *pContext,  | 
9888  |  |   void (*xDestructor)(void*)  | 
9889  |  | );  | 
9890  |  |  | 
9891  |  |  | 
9892  |  | /*  | 
9893  |  | ** A pointer to a structure of the following type is passed as the  | 
9894  |  | ** argument to scored geometry callback registered using  | 
9895  |  | ** sqlite3_rtree_query_callback().  | 
9896  |  | **  | 
9897  |  | ** Note that the first 5 fields of this structure are identical to  | 
9898  |  | ** sqlite3_rtree_geometry.  This structure is a subclass of  | 
9899  |  | ** sqlite3_rtree_geometry.  | 
9900  |  | */  | 
9901  |  | struct sqlite3_rtree_query_info { | 
9902  |  |   void *pContext;                   /* pContext from when function registered */  | 
9903  |  |   int nParam;                       /* Number of function parameters */  | 
9904  |  |   sqlite3_rtree_dbl *aParam;        /* value of function parameters */  | 
9905  |  |   void *pUser;                      /* callback can use this, if desired */  | 
9906  |  |   void (*xDelUser)(void*);          /* function to free pUser */  | 
9907  |  |   sqlite3_rtree_dbl *aCoord;        /* Coordinates of node or entry to check */  | 
9908  |  |   unsigned int *anQueue;            /* Number of pending entries in the queue */  | 
9909  |  |   int nCoord;                       /* Number of coordinates */  | 
9910  |  |   int iLevel;                       /* Level of current node or entry */  | 
9911  |  |   int mxLevel;                      /* The largest iLevel value in the tree */  | 
9912  |  |   sqlite3_int64 iRowid;             /* Rowid for current entry */  | 
9913  |  |   sqlite3_rtree_dbl rParentScore;   /* Score of parent node */  | 
9914  |  |   int eParentWithin;                /* Visibility of parent node */  | 
9915  |  |   int eWithin;                      /* OUT: Visibility */  | 
9916  |  |   sqlite3_rtree_dbl rScore;         /* OUT: Write the score here */  | 
9917  |  |   /* The following fields are only available in 3.8.11 and later */  | 
9918  |  |   sqlite3_value **apSqlParam;       /* Original SQL values of parameters */  | 
9919  |  | };  | 
9920  |  |  | 
9921  |  | /*  | 
9922  |  | ** Allowed values for sqlite3_rtree_query.eWithin and .eParentWithin.  | 
9923  |  | */  | 
9924  |  | #define NOT_WITHIN       0   /* Object completely outside of query region */  | 
9925  |  | #define PARTLY_WITHIN    1   /* Object partially overlaps query region */  | 
9926  |  | #define FULLY_WITHIN     2   /* Object fully contained within query region */  | 
9927  |  |  | 
9928  |  |  | 
9929  |  | #ifdef __cplusplus  | 
9930  |  | }  /* end of the 'extern "C"' block */  | 
9931  |  | #endif  | 
9932  |  |  | 
9933  |  | #endif  /* ifndef _SQLITE3RTREE_H_ */  | 
9934  |  |  | 
9935  |  | /******** End of sqlite3rtree.h *********/  | 
9936  |  | /******** Begin file sqlite3session.h *********/  | 
9937  |  |  | 
9938  |  | #if !defined(__SQLITESESSION_H_) && defined(SQLITE_ENABLE_SESSION)  | 
9939  |  | #define __SQLITESESSION_H_ 1  | 
9940  |  |  | 
9941  |  | /*  | 
9942  |  | ** Make sure we can call this stuff from C++.  | 
9943  |  | */  | 
9944  |  | #ifdef __cplusplus  | 
9945  |  | extern "C" { | 
9946  |  | #endif  | 
9947  |  |  | 
9948  |  |  | 
9949  |  | /*  | 
9950  |  | ** CAPI3REF: Session Object Handle  | 
9951  |  | **  | 
9952  |  | ** An instance of this object is a [session] that can be used to  | 
9953  |  | ** record changes to a database.  | 
9954  |  | */  | 
9955  |  | typedef struct sqlite3_session sqlite3_session;  | 
9956  |  |  | 
9957  |  | /*  | 
9958  |  | ** CAPI3REF: Changeset Iterator Handle  | 
9959  |  | **  | 
9960  |  | ** An instance of this object acts as a cursor for iterating  | 
9961  |  | ** over the elements of a [changeset] or [patchset].  | 
9962  |  | */  | 
9963  |  | typedef struct sqlite3_changeset_iter sqlite3_changeset_iter;  | 
9964  |  |  | 
9965  |  | /*  | 
9966  |  | ** CAPI3REF: Create A New Session Object  | 
9967  |  | ** CONSTRUCTOR: sqlite3_session  | 
9968  |  | **  | 
9969  |  | ** Create a new session object attached to database handle db. If successful,  | 
9970  |  | ** a pointer to the new object is written to *ppSession and SQLITE_OK is  | 
9971  |  | ** returned. If an error occurs, *ppSession is set to NULL and an SQLite  | 
9972  |  | ** error code (e.g. SQLITE_NOMEM) is returned.  | 
9973  |  | **  | 
9974  |  | ** It is possible to create multiple session objects attached to a single  | 
9975  |  | ** database handle.  | 
9976  |  | **  | 
9977  |  | ** Session objects created using this function should be deleted using the  | 
9978  |  | ** [sqlite3session_delete()] function before the database handle that they  | 
9979  |  | ** are attached to is itself closed. If the database handle is closed before  | 
9980  |  | ** the session object is deleted, then the results of calling any session  | 
9981  |  | ** module function, including [sqlite3session_delete()] on the session object  | 
9982  |  | ** are undefined.  | 
9983  |  | **  | 
9984  |  | ** Because the session module uses the [sqlite3_preupdate_hook()] API, it  | 
9985  |  | ** is not possible for an application to register a pre-update hook on a  | 
9986  |  | ** database handle that has one or more session objects attached. Nor is  | 
9987  |  | ** it possible to create a session object attached to a database handle for  | 
9988  |  | ** which a pre-update hook is already defined. The results of attempting  | 
9989  |  | ** either of these things are undefined.  | 
9990  |  | **  | 
9991  |  | ** The session object will be used to create changesets for tables in  | 
9992  |  | ** database zDb, where zDb is either "main", or "temp", or the name of an  | 
9993  |  | ** attached database. It is not an error if database zDb is not attached  | 
9994  |  | ** to the database when the session object is created.  | 
9995  |  | */  | 
9996  |  | SQLITE_API int sqlite3session_create(  | 
9997  |  |   sqlite3 *db,                    /* Database handle */  | 
9998  |  |   const char *zDb,                /* Name of db (e.g. "main") */  | 
9999  |  |   sqlite3_session **ppSession     /* OUT: New session object */  | 
10000  |  | );  | 
10001  |  |  | 
10002  |  | /*  | 
10003  |  | ** CAPI3REF: Delete A Session Object  | 
10004  |  | ** DESTRUCTOR: sqlite3_session  | 
10005  |  | **  | 
10006  |  | ** Delete a session object previously allocated using  | 
10007  |  | ** [sqlite3session_create()]. Once a session object has been deleted, the  | 
10008  |  | ** results of attempting to use pSession with any other session module  | 
10009  |  | ** function are undefined.  | 
10010  |  | **  | 
10011  |  | ** Session objects must be deleted before the database handle to which they  | 
10012  |  | ** are attached is closed. Refer to the documentation for  | 
10013  |  | ** [sqlite3session_create()] for details.  | 
10014  |  | */  | 
10015  |  | SQLITE_API void sqlite3session_delete(sqlite3_session *pSession);  | 
10016  |  |  | 
10017  |  |  | 
10018  |  | /*  | 
10019  |  | ** CAPI3REF: Enable Or Disable A Session Object  | 
10020  |  | ** METHOD: sqlite3_session  | 
10021  |  | **  | 
10022  |  | ** Enable or disable the recording of changes by a session object. When  | 
10023  |  | ** enabled, a session object records changes made to the database. When  | 
10024  |  | ** disabled - it does not. A newly created session object is enabled.  | 
10025  |  | ** Refer to the documentation for [sqlite3session_changeset()] for further  | 
10026  |  | ** details regarding how enabling and disabling a session object affects  | 
10027  |  | ** the eventual changesets.  | 
10028  |  | **  | 
10029  |  | ** Passing zero to this function disables the session. Passing a value  | 
10030  |  | ** greater than zero enables it. Passing a value less than zero is a  | 
10031  |  | ** no-op, and may be used to query the current state of the session.  | 
10032  |  | **  | 
10033  |  | ** The return value indicates the final state of the session object: 0 if  | 
10034  |  | ** the session is disabled, or 1 if it is enabled.  | 
10035  |  | */  | 
10036  |  | SQLITE_API int sqlite3session_enable(sqlite3_session *pSession, int bEnable);  | 
10037  |  |  | 
10038  |  | /*  | 
10039  |  | ** CAPI3REF: Set Or Clear the Indirect Change Flag  | 
10040  |  | ** METHOD: sqlite3_session  | 
10041  |  | **  | 
10042  |  | ** Each change recorded by a session object is marked as either direct or  | 
10043  |  | ** indirect. A change is marked as indirect if either:  | 
10044  |  | **  | 
10045  |  | ** <ul>  | 
10046  |  | **   <li> The session object "indirect" flag is set when the change is  | 
10047  |  | **        made, or  | 
10048  |  | **   <li> The change is made by an SQL trigger or foreign key action  | 
10049  |  | **        instead of directly as a result of a users SQL statement.  | 
10050  |  | ** </ul>  | 
10051  |  | **  | 
10052  |  | ** If a single row is affected by more than one operation within a session,  | 
10053  |  | ** then the change is considered indirect if all operations meet the criteria  | 
10054  |  | ** for an indirect change above, or direct otherwise.  | 
10055  |  | **  | 
10056  |  | ** This function is used to set, clear or query the session object indirect  | 
10057  |  | ** flag.  If the second argument passed to this function is zero, then the  | 
10058  |  | ** indirect flag is cleared. If it is greater than zero, the indirect flag  | 
10059  |  | ** is set. Passing a value less than zero does not modify the current value  | 
10060  |  | ** of the indirect flag, and may be used to query the current state of the  | 
10061  |  | ** indirect flag for the specified session object.  | 
10062  |  | **  | 
10063  |  | ** The return value indicates the final state of the indirect flag: 0 if  | 
10064  |  | ** it is clear, or 1 if it is set.  | 
10065  |  | */  | 
10066  |  | SQLITE_API int sqlite3session_indirect(sqlite3_session *pSession, int bIndirect);  | 
10067  |  |  | 
10068  |  | /*  | 
10069  |  | ** CAPI3REF: Attach A Table To A Session Object  | 
10070  |  | ** METHOD: sqlite3_session  | 
10071  |  | **  | 
10072  |  | ** If argument zTab is not NULL, then it is the name of a table to attach  | 
10073  |  | ** to the session object passed as the first argument. All subsequent changes  | 
10074  |  | ** made to the table while the session object is enabled will be recorded. See  | 
10075  |  | ** documentation for [sqlite3session_changeset()] for further details.  | 
10076  |  | **  | 
10077  |  | ** Or, if argument zTab is NULL, then changes are recorded for all tables  | 
10078  |  | ** in the database. If additional tables are added to the database (by  | 
10079  |  | ** executing "CREATE TABLE" statements) after this call is made, changes for  | 
10080  |  | ** the new tables are also recorded.  | 
10081  |  | **  | 
10082  |  | ** Changes can only be recorded for tables that have a PRIMARY KEY explicitly  | 
10083  |  | ** defined as part of their CREATE TABLE statement. It does not matter if the  | 
10084  |  | ** PRIMARY KEY is an "INTEGER PRIMARY KEY" (rowid alias) or not. The PRIMARY  | 
10085  |  | ** KEY may consist of a single column, or may be a composite key.  | 
10086  |  | **  | 
10087  |  | ** It is not an error if the named table does not exist in the database. Nor  | 
10088  |  | ** is it an error if the named table does not have a PRIMARY KEY. However,  | 
10089  |  | ** no changes will be recorded in either of these scenarios.  | 
10090  |  | **  | 
10091  |  | ** Changes are not recorded for individual rows that have NULL values stored  | 
10092  |  | ** in one or more of their PRIMARY KEY columns.  | 
10093  |  | **  | 
10094  |  | ** SQLITE_OK is returned if the call completes without error. Or, if an error  | 
10095  |  | ** occurs, an SQLite error code (e.g. SQLITE_NOMEM) is returned.  | 
10096  |  | **  | 
10097  |  | ** <h3>Special sqlite_stat1 Handling</h3>  | 
10098  |  | **  | 
10099  |  | ** As of SQLite version 3.22.0, the "sqlite_stat1" table is an exception to  | 
10100  |  | ** some of the rules above. In SQLite, the schema of sqlite_stat1 is:  | 
10101  |  | **  <pre>  | 
10102  |  | **        CREATE TABLE sqlite_stat1(tbl,idx,stat)  | 
10103  |  | **  </pre>  | 
10104  |  | **  | 
10105  |  | ** Even though sqlite_stat1 does not have a PRIMARY KEY, changes are  | 
10106  |  | ** recorded for it as if the PRIMARY KEY is (tbl,idx). Additionally, changes  | 
10107  |  | ** are recorded for rows for which (idx IS NULL) is true. However, for such  | 
10108  |  | ** rows a zero-length blob (SQL value X'') is stored in the changeset or  | 
10109  |  | ** patchset instead of a NULL value. This allows such changesets to be  | 
10110  |  | ** manipulated by legacy implementations of sqlite3changeset_invert(),  | 
10111  |  | ** concat() and similar.  | 
10112  |  | **  | 
10113  |  | ** The sqlite3changeset_apply() function automatically converts the  | 
10114  |  | ** zero-length blob back to a NULL value when updating the sqlite_stat1  | 
10115  |  | ** table. However, if the application calls sqlite3changeset_new(),  | 
10116  |  | ** sqlite3changeset_old() or sqlite3changeset_conflict on a changeset  | 
10117  |  | ** iterator directly (including on a changeset iterator passed to a  | 
10118  |  | ** conflict-handler callback) then the X'' value is returned. The application  | 
10119  |  | ** must translate X'' to NULL itself if required.  | 
10120  |  | **  | 
10121  |  | ** Legacy (older than 3.22.0) versions of the sessions module cannot capture  | 
10122  |  | ** changes made to the sqlite_stat1 table. Legacy versions of the  | 
10123  |  | ** sqlite3changeset_apply() function silently ignore any modifications to the  | 
10124  |  | ** sqlite_stat1 table that are part of a changeset or patchset.  | 
10125  |  | */  | 
10126  |  | SQLITE_API int sqlite3session_attach(  | 
10127  |  |   sqlite3_session *pSession,      /* Session object */  | 
10128  |  |   const char *zTab                /* Table name */  | 
10129  |  | );  | 
10130  |  |  | 
10131  |  | /*  | 
10132  |  | ** CAPI3REF: Set a table filter on a Session Object.  | 
10133  |  | ** METHOD: sqlite3_session  | 
10134  |  | **  | 
10135  |  | ** The second argument (xFilter) is the "filter callback". For changes to rows  | 
10136  |  | ** in tables that are not attached to the Session object, the filter is called  | 
10137  |  | ** to determine whether changes to the table's rows should be tracked or not.  | 
10138  |  | ** If xFilter returns 0, changes are not tracked. Note that once a table is  | 
10139  |  | ** attached, xFilter will not be called again.  | 
10140  |  | */  | 
10141  |  | SQLITE_API void sqlite3session_table_filter(  | 
10142  |  |   sqlite3_session *pSession,      /* Session object */  | 
10143  |  |   int(*xFilter)(  | 
10144  |  |     void *pCtx,                   /* Copy of third arg to _filter_table() */  | 
10145  |  |     const char *zTab              /* Table name */  | 
10146  |  |   ),  | 
10147  |  |   void *pCtx                      /* First argument passed to xFilter */  | 
10148  |  | );  | 
10149  |  |  | 
10150  |  | /*  | 
10151  |  | ** CAPI3REF: Generate A Changeset From A Session Object  | 
10152  |  | ** METHOD: sqlite3_session  | 
10153  |  | **  | 
10154  |  | ** Obtain a changeset containing changes to the tables attached to the  | 
10155  |  | ** session object passed as the first argument. If successful,  | 
10156  |  | ** set *ppChangeset to point to a buffer containing the changeset  | 
10157  |  | ** and *pnChangeset to the size of the changeset in bytes before returning  | 
10158  |  | ** SQLITE_OK. If an error occurs, set both *ppChangeset and *pnChangeset to  | 
10159  |  | ** zero and return an SQLite error code.  | 
10160  |  | **  | 
10161  |  | ** A changeset consists of zero or more INSERT, UPDATE and/or DELETE changes,  | 
10162  |  | ** each representing a change to a single row of an attached table. An INSERT  | 
10163  |  | ** change contains the values of each field of a new database row. A DELETE  | 
10164  |  | ** contains the original values of each field of a deleted database row. An  | 
10165  |  | ** UPDATE change contains the original values of each field of an updated  | 
10166  |  | ** database row along with the updated values for each updated non-primary-key  | 
10167  |  | ** column. It is not possible for an UPDATE change to represent a change that  | 
10168  |  | ** modifies the values of primary key columns. If such a change is made, it  | 
10169  |  | ** is represented in a changeset as a DELETE followed by an INSERT.  | 
10170  |  | **  | 
10171  |  | ** Changes are not recorded for rows that have NULL values stored in one or  | 
10172  |  | ** more of their PRIMARY KEY columns. If such a row is inserted or deleted,  | 
10173  |  | ** no corresponding change is present in the changesets returned by this  | 
10174  |  | ** function. If an existing row with one or more NULL values stored in  | 
10175  |  | ** PRIMARY KEY columns is updated so that all PRIMARY KEY columns are non-NULL,  | 
10176  |  | ** only an INSERT is appears in the changeset. Similarly, if an existing row  | 
10177  |  | ** with non-NULL PRIMARY KEY values is updated so that one or more of its  | 
10178  |  | ** PRIMARY KEY columns are set to NULL, the resulting changeset contains a  | 
10179  |  | ** DELETE change only.  | 
10180  |  | **  | 
10181  |  | ** The contents of a changeset may be traversed using an iterator created  | 
10182  |  | ** using the [sqlite3changeset_start()] API. A changeset may be applied to  | 
10183  |  | ** a database with a compatible schema using the [sqlite3changeset_apply()]  | 
10184  |  | ** API.  | 
10185  |  | **  | 
10186  |  | ** Within a changeset generated by this function, all changes related to a  | 
10187  |  | ** single table are grouped together. In other words, when iterating through  | 
10188  |  | ** a changeset or when applying a changeset to a database, all changes related  | 
10189  |  | ** to a single table are processed before moving on to the next table. Tables  | 
10190  |  | ** are sorted in the same order in which they were attached (or auto-attached)  | 
10191  |  | ** to the sqlite3_session object. The order in which the changes related to  | 
10192  |  | ** a single table are stored is undefined.  | 
10193  |  | **  | 
10194  |  | ** Following a successful call to this function, it is the responsibility of  | 
10195  |  | ** the caller to eventually free the buffer that *ppChangeset points to using  | 
10196  |  | ** [sqlite3_free()].  | 
10197  |  | **  | 
10198  |  | ** <h3>Changeset Generation</h3>  | 
10199  |  | **  | 
10200  |  | ** Once a table has been attached to a session object, the session object  | 
10201  |  | ** records the primary key values of all new rows inserted into the table.  | 
10202  |  | ** It also records the original primary key and other column values of any  | 
10203  |  | ** deleted or updated rows. For each unique primary key value, data is only  | 
10204  |  | ** recorded once - the first time a row with said primary key is inserted,  | 
10205  |  | ** updated or deleted in the lifetime of the session.  | 
10206  |  | **  | 
10207  |  | ** There is one exception to the previous paragraph: when a row is inserted,  | 
10208  |  | ** updated or deleted, if one or more of its primary key columns contain a  | 
10209  |  | ** NULL value, no record of the change is made.  | 
10210  |  | **  | 
10211  |  | ** The session object therefore accumulates two types of records - those  | 
10212  |  | ** that consist of primary key values only (created when the user inserts  | 
10213  |  | ** a new record) and those that consist of the primary key values and the  | 
10214  |  | ** original values of other table columns (created when the users deletes  | 
10215  |  | ** or updates a record).  | 
10216  |  | **  | 
10217  |  | ** When this function is called, the requested changeset is created using  | 
10218  |  | ** both the accumulated records and the current contents of the database  | 
10219  |  | ** file. Specifically:  | 
10220  |  | **  | 
10221  |  | ** <ul>  | 
10222  |  | **   <li> For each record generated by an insert, the database is queried  | 
10223  |  | **        for a row with a matching primary key. If one is found, an INSERT  | 
10224  |  | **        change is added to the changeset. If no such row is found, no change  | 
10225  |  | **        is added to the changeset.  | 
10226  |  | **  | 
10227  |  | **   <li> For each record generated by an update or delete, the database is  | 
10228  |  | **        queried for a row with a matching primary key. If such a row is  | 
10229  |  | **        found and one or more of the non-primary key fields have been  | 
10230  |  | **        modified from their original values, an UPDATE change is added to  | 
10231  |  | **        the changeset. Or, if no such row is found in the table, a DELETE  | 
10232  |  | **        change is added to the changeset. If there is a row with a matching  | 
10233  |  | **        primary key in the database, but all fields contain their original  | 
10234  |  | **        values, no change is added to the changeset.  | 
10235  |  | ** </ul>  | 
10236  |  | **  | 
10237  |  | ** This means, amongst other things, that if a row is inserted and then later  | 
10238  |  | ** deleted while a session object is active, neither the insert nor the delete  | 
10239  |  | ** will be present in the changeset. Or if a row is deleted and then later a  | 
10240  |  | ** row with the same primary key values inserted while a session object is  | 
10241  |  | ** active, the resulting changeset will contain an UPDATE change instead of  | 
10242  |  | ** a DELETE and an INSERT.  | 
10243  |  | **  | 
10244  |  | ** When a session object is disabled (see the [sqlite3session_enable()] API),  | 
10245  |  | ** it does not accumulate records when rows are inserted, updated or deleted.  | 
10246  |  | ** This may appear to have some counter-intuitive effects if a single row  | 
10247  |  | ** is written to more than once during a session. For example, if a row  | 
10248  |  | ** is inserted while a session object is enabled, then later deleted while  | 
10249  |  | ** the same session object is disabled, no INSERT record will appear in the  | 
10250  |  | ** changeset, even though the delete took place while the session was disabled.  | 
10251  |  | ** Or, if one field of a row is updated while a session is disabled, and  | 
10252  |  | ** another field of the same row is updated while the session is enabled, the  | 
10253  |  | ** resulting changeset will contain an UPDATE change that updates both fields.  | 
10254  |  | */  | 
10255  |  | SQLITE_API int sqlite3session_changeset(  | 
10256  |  |   sqlite3_session *pSession,      /* Session object */  | 
10257  |  |   int *pnChangeset,               /* OUT: Size of buffer at *ppChangeset */  | 
10258  |  |   void **ppChangeset              /* OUT: Buffer containing changeset */  | 
10259  |  | );  | 
10260  |  |  | 
10261  |  | /*  | 
10262  |  | ** CAPI3REF: Load The Difference Between Tables Into A Session  | 
10263  |  | ** METHOD: sqlite3_session  | 
10264  |  | **  | 
10265  |  | ** If it is not already attached to the session object passed as the first  | 
10266  |  | ** argument, this function attaches table zTbl in the same manner as the  | 
10267  |  | ** [sqlite3session_attach()] function. If zTbl does not exist, or if it  | 
10268  |  | ** does not have a primary key, this function is a no-op (but does not return  | 
10269  |  | ** an error).  | 
10270  |  | **  | 
10271  |  | ** Argument zFromDb must be the name of a database ("main", "temp" etc.) | 
10272  |  | ** attached to the same database handle as the session object that contains  | 
10273  |  | ** a table compatible with the table attached to the session by this function.  | 
10274  |  | ** A table is considered compatible if it:  | 
10275  |  | **  | 
10276  |  | ** <ul>  | 
10277  |  | **   <li> Has the same name,  | 
10278  |  | **   <li> Has the same set of columns declared in the same order, and  | 
10279  |  | **   <li> Has the same PRIMARY KEY definition.  | 
10280  |  | ** </ul>  | 
10281  |  | **  | 
10282  |  | ** If the tables are not compatible, SQLITE_SCHEMA is returned. If the tables  | 
10283  |  | ** are compatible but do not have any PRIMARY KEY columns, it is not an error  | 
10284  |  | ** but no changes are added to the session object. As with other session  | 
10285  |  | ** APIs, tables without PRIMARY KEYs are simply ignored.  | 
10286  |  | **  | 
10287  |  | ** This function adds a set of changes to the session object that could be  | 
10288  |  | ** used to update the table in database zFrom (call this the "from-table")  | 
10289  |  | ** so that its content is the same as the table attached to the session  | 
10290  |  | ** object (call this the "to-table"). Specifically:  | 
10291  |  | **  | 
10292  |  | ** <ul>  | 
10293  |  | **   <li> For each row (primary key) that exists in the to-table but not in  | 
10294  |  | **     the from-table, an INSERT record is added to the session object.  | 
10295  |  | **  | 
10296  |  | **   <li> For each row (primary key) that exists in the to-table but not in  | 
10297  |  | **     the from-table, a DELETE record is added to the session object.  | 
10298  |  | **  | 
10299  |  | **   <li> For each row (primary key) that exists in both tables, but features  | 
10300  |  | **     different non-PK values in each, an UPDATE record is added to the  | 
10301  |  | **     session.  | 
10302  |  | ** </ul>  | 
10303  |  | **  | 
10304  |  | ** To clarify, if this function is called and then a changeset constructed  | 
10305  |  | ** using [sqlite3session_changeset()], then after applying that changeset to  | 
10306  |  | ** database zFrom the contents of the two compatible tables would be  | 
10307  |  | ** identical.  | 
10308  |  | **  | 
10309  |  | ** It an error if database zFrom does not exist or does not contain the  | 
10310  |  | ** required compatible table.  | 
10311  |  | **  | 
10312  |  | ** If the operation is successful, SQLITE_OK is returned. Otherwise, an SQLite  | 
10313  |  | ** error code. In this case, if argument pzErrMsg is not NULL, *pzErrMsg  | 
10314  |  | ** may be set to point to a buffer containing an English language error  | 
10315  |  | ** message. It is the responsibility of the caller to free this buffer using  | 
10316  |  | ** sqlite3_free().  | 
10317  |  | */  | 
10318  |  | SQLITE_API int sqlite3session_diff(  | 
10319  |  |   sqlite3_session *pSession,  | 
10320  |  |   const char *zFromDb,  | 
10321  |  |   const char *zTbl,  | 
10322  |  |   char **pzErrMsg  | 
10323  |  | );  | 
10324  |  |  | 
10325  |  |  | 
10326  |  | /*  | 
10327  |  | ** CAPI3REF: Generate A Patchset From A Session Object  | 
10328  |  | ** METHOD: sqlite3_session  | 
10329  |  | **  | 
10330  |  | ** The differences between a patchset and a changeset are that:  | 
10331  |  | **  | 
10332  |  | ** <ul>  | 
10333  |  | **   <li> DELETE records consist of the primary key fields only. The  | 
10334  |  | **        original values of other fields are omitted.  | 
10335  |  | **   <li> The original values of any modified fields are omitted from  | 
10336  |  | **        UPDATE records.  | 
10337  |  | ** </ul>  | 
10338  |  | **  | 
10339  |  | ** A patchset blob may be used with up to date versions of all  | 
10340  |  | ** sqlite3changeset_xxx API functions except for sqlite3changeset_invert(),  | 
10341  |  | ** which returns SQLITE_CORRUPT if it is passed a patchset. Similarly,  | 
10342  |  | ** attempting to use a patchset blob with old versions of the  | 
10343  |  | ** sqlite3changeset_xxx APIs also provokes an SQLITE_CORRUPT error.  | 
10344  |  | **  | 
10345  |  | ** Because the non-primary key "old.*" fields are omitted, no  | 
10346  |  | ** SQLITE_CHANGESET_DATA conflicts can be detected or reported if a patchset  | 
10347  |  | ** is passed to the sqlite3changeset_apply() API. Other conflict types work  | 
10348  |  | ** in the same way as for changesets.  | 
10349  |  | **  | 
10350  |  | ** Changes within a patchset are ordered in the same way as for changesets  | 
10351  |  | ** generated by the sqlite3session_changeset() function (i.e. all changes for  | 
10352  |  | ** a single table are grouped together, tables appear in the order in which  | 
10353  |  | ** they were attached to the session object).  | 
10354  |  | */  | 
10355  |  | SQLITE_API int sqlite3session_patchset(  | 
10356  |  |   sqlite3_session *pSession,      /* Session object */  | 
10357  |  |   int *pnPatchset,                /* OUT: Size of buffer at *ppPatchset */  | 
10358  |  |   void **ppPatchset               /* OUT: Buffer containing patchset */  | 
10359  |  | );  | 
10360  |  |  | 
10361  |  | /*  | 
10362  |  | ** CAPI3REF: Test if a changeset has recorded any changes.  | 
10363  |  | **  | 
10364  |  | ** Return non-zero if no changes to attached tables have been recorded by  | 
10365  |  | ** the session object passed as the first argument. Otherwise, if one or  | 
10366  |  | ** more changes have been recorded, return zero.  | 
10367  |  | **  | 
10368  |  | ** Even if this function returns zero, it is possible that calling  | 
10369  |  | ** [sqlite3session_changeset()] on the session handle may still return a  | 
10370  |  | ** changeset that contains no changes. This can happen when a row in  | 
10371  |  | ** an attached table is modified and then later on the original values  | 
10372  |  | ** are restored. However, if this function returns non-zero, then it is  | 
10373  |  | ** guaranteed that a call to sqlite3session_changeset() will return a  | 
10374  |  | ** changeset containing zero changes.  | 
10375  |  | */  | 
10376  |  | SQLITE_API int sqlite3session_isempty(sqlite3_session *pSession);  | 
10377  |  |  | 
10378  |  | /*  | 
10379  |  | ** CAPI3REF: Create An Iterator To Traverse A Changeset  | 
10380  |  | ** CONSTRUCTOR: sqlite3_changeset_iter  | 
10381  |  | **  | 
10382  |  | ** Create an iterator used to iterate through the contents of a changeset.  | 
10383  |  | ** If successful, *pp is set to point to the iterator handle and SQLITE_OK  | 
10384  |  | ** is returned. Otherwise, if an error occurs, *pp is set to zero and an  | 
10385  |  | ** SQLite error code is returned.  | 
10386  |  | **  | 
10387  |  | ** The following functions can be used to advance and query a changeset  | 
10388  |  | ** iterator created by this function:  | 
10389  |  | **  | 
10390  |  | ** <ul>  | 
10391  |  | **   <li> [sqlite3changeset_next()]  | 
10392  |  | **   <li> [sqlite3changeset_op()]  | 
10393  |  | **   <li> [sqlite3changeset_new()]  | 
10394  |  | **   <li> [sqlite3changeset_old()]  | 
10395  |  | ** </ul>  | 
10396  |  | **  | 
10397  |  | ** It is the responsibility of the caller to eventually destroy the iterator  | 
10398  |  | ** by passing it to [sqlite3changeset_finalize()]. The buffer containing the  | 
10399  |  | ** changeset (pChangeset) must remain valid until after the iterator is  | 
10400  |  | ** destroyed.  | 
10401  |  | **  | 
10402  |  | ** Assuming the changeset blob was created by one of the  | 
10403  |  | ** [sqlite3session_changeset()], [sqlite3changeset_concat()] or  | 
10404  |  | ** [sqlite3changeset_invert()] functions, all changes within the changeset  | 
10405  |  | ** that apply to a single table are grouped together. This means that when  | 
10406  |  | ** an application iterates through a changeset using an iterator created by  | 
10407  |  | ** this function, all changes that relate to a single table are visited  | 
10408  |  | ** consecutively. There is no chance that the iterator will visit a change  | 
10409  |  | ** the applies to table X, then one for table Y, and then later on visit  | 
10410  |  | ** another change for table X.  | 
10411  |  | **  | 
10412  |  | ** The behavior of sqlite3changeset_start_v2() and its streaming equivalent  | 
10413  |  | ** may be modified by passing a combination of  | 
10414  |  | ** [SQLITE_CHANGESETSTART_INVERT | supported flags] as the 4th parameter.  | 
10415  |  | **  | 
10416  |  | ** Note that the sqlite3changeset_start_v2() API is still <b>experimental</b>  | 
10417  |  | ** and therefore subject to change.  | 
10418  |  | */  | 
10419  |  | SQLITE_API int sqlite3changeset_start(  | 
10420  |  |   sqlite3_changeset_iter **pp,    /* OUT: New changeset iterator handle */  | 
10421  |  |   int nChangeset,                 /* Size of changeset blob in bytes */  | 
10422  |  |   void *pChangeset                /* Pointer to blob containing changeset */  | 
10423  |  | );  | 
10424  |  | SQLITE_API int sqlite3changeset_start_v2(  | 
10425  |  |   sqlite3_changeset_iter **pp,    /* OUT: New changeset iterator handle */  | 
10426  |  |   int nChangeset,                 /* Size of changeset blob in bytes */  | 
10427  |  |   void *pChangeset,               /* Pointer to blob containing changeset */  | 
10428  |  |   int flags                       /* SESSION_CHANGESETSTART_* flags */  | 
10429  |  | );  | 
10430  |  |  | 
10431  |  | /*  | 
10432  |  | ** CAPI3REF: Flags for sqlite3changeset_start_v2  | 
10433  |  | **  | 
10434  |  | ** The following flags may passed via the 4th parameter to  | 
10435  |  | ** [sqlite3changeset_start_v2] and [sqlite3changeset_start_v2_strm]:  | 
10436  |  | **  | 
10437  |  | ** <dt>SQLITE_CHANGESETAPPLY_INVERT <dd>  | 
10438  |  | **   Invert the changeset while iterating through it. This is equivalent to  | 
10439  |  | **   inverting a changeset using sqlite3changeset_invert() before applying it.  | 
10440  |  | **   It is an error to specify this flag with a patchset.  | 
10441  |  | */  | 
10442  |  | #define SQLITE_CHANGESETSTART_INVERT        0x0002  | 
10443  |  |  | 
10444  |  |  | 
10445  |  | /*  | 
10446  |  | ** CAPI3REF: Advance A Changeset Iterator  | 
10447  |  | ** METHOD: sqlite3_changeset_iter  | 
10448  |  | **  | 
10449  |  | ** This function may only be used with iterators created by the function  | 
10450  |  | ** [sqlite3changeset_start()]. If it is called on an iterator passed to  | 
10451  |  | ** a conflict-handler callback by [sqlite3changeset_apply()], SQLITE_MISUSE  | 
10452  |  | ** is returned and the call has no effect.  | 
10453  |  | **  | 
10454  |  | ** Immediately after an iterator is created by sqlite3changeset_start(), it  | 
10455  |  | ** does not point to any change in the changeset. Assuming the changeset  | 
10456  |  | ** is not empty, the first call to this function advances the iterator to  | 
10457  |  | ** point to the first change in the changeset. Each subsequent call advances  | 
10458  |  | ** the iterator to point to the next change in the changeset (if any). If  | 
10459  |  | ** no error occurs and the iterator points to a valid change after a call  | 
10460  |  | ** to sqlite3changeset_next() has advanced it, SQLITE_ROW is returned.  | 
10461  |  | ** Otherwise, if all changes in the changeset have already been visited,  | 
10462  |  | ** SQLITE_DONE is returned.  | 
10463  |  | **  | 
10464  |  | ** If an error occurs, an SQLite error code is returned. Possible error  | 
10465  |  | ** codes include SQLITE_CORRUPT (if the changeset buffer is corrupt) or  | 
10466  |  | ** SQLITE_NOMEM.  | 
10467  |  | */  | 
10468  |  | SQLITE_API int sqlite3changeset_next(sqlite3_changeset_iter *pIter);  | 
10469  |  |  | 
10470  |  | /*  | 
10471  |  | ** CAPI3REF: Obtain The Current Operation From A Changeset Iterator  | 
10472  |  | ** METHOD: sqlite3_changeset_iter  | 
10473  |  | **  | 
10474  |  | ** The pIter argument passed to this function may either be an iterator  | 
10475  |  | ** passed to a conflict-handler by [sqlite3changeset_apply()], or an iterator  | 
10476  |  | ** created by [sqlite3changeset_start()]. In the latter case, the most recent  | 
10477  |  | ** call to [sqlite3changeset_next()] must have returned [SQLITE_ROW]. If this  | 
10478  |  | ** is not the case, this function returns [SQLITE_MISUSE].  | 
10479  |  | **  | 
10480  |  | ** If argument pzTab is not NULL, then *pzTab is set to point to a  | 
10481  |  | ** nul-terminated utf-8 encoded string containing the name of the table  | 
10482  |  | ** affected by the current change. The buffer remains valid until either  | 
10483  |  | ** sqlite3changeset_next() is called on the iterator or until the  | 
10484  |  | ** conflict-handler function returns. If pnCol is not NULL, then *pnCol is  | 
10485  |  | ** set to the number of columns in the table affected by the change. If  | 
10486  |  | ** pbIndirect is not NULL, then *pbIndirect is set to true (1) if the change  | 
10487  |  | ** is an indirect change, or false (0) otherwise. See the documentation for  | 
10488  |  | ** [sqlite3session_indirect()] for a description of direct and indirect  | 
10489  |  | ** changes. Finally, if pOp is not NULL, then *pOp is set to one of  | 
10490  |  | ** [SQLITE_INSERT], [SQLITE_DELETE] or [SQLITE_UPDATE], depending on the  | 
10491  |  | ** type of change that the iterator currently points to.  | 
10492  |  | **  | 
10493  |  | ** If no error occurs, SQLITE_OK is returned. If an error does occur, an  | 
10494  |  | ** SQLite error code is returned. The values of the output variables may not  | 
10495  |  | ** be trusted in this case.  | 
10496  |  | */  | 
10497  |  | SQLITE_API int sqlite3changeset_op(  | 
10498  |  |   sqlite3_changeset_iter *pIter,  /* Iterator object */  | 
10499  |  |   const char **pzTab,             /* OUT: Pointer to table name */  | 
10500  |  |   int *pnCol,                     /* OUT: Number of columns in table */  | 
10501  |  |   int *pOp,                       /* OUT: SQLITE_INSERT, DELETE or UPDATE */  | 
10502  |  |   int *pbIndirect                 /* OUT: True for an 'indirect' change */  | 
10503  |  | );  | 
10504  |  |  | 
10505  |  | /*  | 
10506  |  | ** CAPI3REF: Obtain The Primary Key Definition Of A Table  | 
10507  |  | ** METHOD: sqlite3_changeset_iter  | 
10508  |  | **  | 
10509  |  | ** For each modified table, a changeset includes the following:  | 
10510  |  | **  | 
10511  |  | ** <ul>  | 
10512  |  | **   <li> The number of columns in the table, and  | 
10513  |  | **   <li> Which of those columns make up the tables PRIMARY KEY.  | 
10514  |  | ** </ul>  | 
10515  |  | **  | 
10516  |  | ** This function is used to find which columns comprise the PRIMARY KEY of  | 
10517  |  | ** the table modified by the change that iterator pIter currently points to.  | 
10518  |  | ** If successful, *pabPK is set to point to an array of nCol entries, where  | 
10519  |  | ** nCol is the number of columns in the table. Elements of *pabPK are set to  | 
10520  |  | ** 0x01 if the corresponding column is part of the tables primary key, or  | 
10521  |  | ** 0x00 if it is not.  | 
10522  |  | **  | 
10523  |  | ** If argument pnCol is not NULL, then *pnCol is set to the number of columns  | 
10524  |  | ** in the table.  | 
10525  |  | **  | 
10526  |  | ** If this function is called when the iterator does not point to a valid  | 
10527  |  | ** entry, SQLITE_MISUSE is returned and the output variables zeroed. Otherwise,  | 
10528  |  | ** SQLITE_OK is returned and the output variables populated as described  | 
10529  |  | ** above.  | 
10530  |  | */  | 
10531  |  | SQLITE_API int sqlite3changeset_pk(  | 
10532  |  |   sqlite3_changeset_iter *pIter,  /* Iterator object */  | 
10533  |  |   unsigned char **pabPK,          /* OUT: Array of boolean - true for PK cols */  | 
10534  |  |   int *pnCol                      /* OUT: Number of entries in output array */  | 
10535  |  | );  | 
10536  |  |  | 
10537  |  | /*  | 
10538  |  | ** CAPI3REF: Obtain old.* Values From A Changeset Iterator  | 
10539  |  | ** METHOD: sqlite3_changeset_iter  | 
10540  |  | **  | 
10541  |  | ** The pIter argument passed to this function may either be an iterator  | 
10542  |  | ** passed to a conflict-handler by [sqlite3changeset_apply()], or an iterator  | 
10543  |  | ** created by [sqlite3changeset_start()]. In the latter case, the most recent  | 
10544  |  | ** call to [sqlite3changeset_next()] must have returned SQLITE_ROW.  | 
10545  |  | ** Furthermore, it may only be called if the type of change that the iterator  | 
10546  |  | ** currently points to is either [SQLITE_DELETE] or [SQLITE_UPDATE]. Otherwise,  | 
10547  |  | ** this function returns [SQLITE_MISUSE] and sets *ppValue to NULL.  | 
10548  |  | **  | 
10549  |  | ** Argument iVal must be greater than or equal to 0, and less than the number  | 
10550  |  | ** of columns in the table affected by the current change. Otherwise,  | 
10551  |  | ** [SQLITE_RANGE] is returned and *ppValue is set to NULL.  | 
10552  |  | **  | 
10553  |  | ** If successful, this function sets *ppValue to point to a protected  | 
10554  |  | ** sqlite3_value object containing the iVal'th value from the vector of  | 
10555  |  | ** original row values stored as part of the UPDATE or DELETE change and  | 
10556  |  | ** returns SQLITE_OK. The name of the function comes from the fact that this  | 
10557  |  | ** is similar to the "old.*" columns available to update or delete triggers.  | 
10558  |  | **  | 
10559  |  | ** If some other error occurs (e.g. an OOM condition), an SQLite error code  | 
10560  |  | ** is returned and *ppValue is set to NULL.  | 
10561  |  | */  | 
10562  |  | SQLITE_API int sqlite3changeset_old(  | 
10563  |  |   sqlite3_changeset_iter *pIter,  /* Changeset iterator */  | 
10564  |  |   int iVal,                       /* Column number */  | 
10565  |  |   sqlite3_value **ppValue         /* OUT: Old value (or NULL pointer) */  | 
10566  |  | );  | 
10567  |  |  | 
10568  |  | /*  | 
10569  |  | ** CAPI3REF: Obtain new.* Values From A Changeset Iterator  | 
10570  |  | ** METHOD: sqlite3_changeset_iter  | 
10571  |  | **  | 
10572  |  | ** The pIter argument passed to this function may either be an iterator  | 
10573  |  | ** passed to a conflict-handler by [sqlite3changeset_apply()], or an iterator  | 
10574  |  | ** created by [sqlite3changeset_start()]. In the latter case, the most recent  | 
10575  |  | ** call to [sqlite3changeset_next()] must have returned SQLITE_ROW.  | 
10576  |  | ** Furthermore, it may only be called if the type of change that the iterator  | 
10577  |  | ** currently points to is either [SQLITE_UPDATE] or [SQLITE_INSERT]. Otherwise,  | 
10578  |  | ** this function returns [SQLITE_MISUSE] and sets *ppValue to NULL.  | 
10579  |  | **  | 
10580  |  | ** Argument iVal must be greater than or equal to 0, and less than the number  | 
10581  |  | ** of columns in the table affected by the current change. Otherwise,  | 
10582  |  | ** [SQLITE_RANGE] is returned and *ppValue is set to NULL.  | 
10583  |  | **  | 
10584  |  | ** If successful, this function sets *ppValue to point to a protected  | 
10585  |  | ** sqlite3_value object containing the iVal'th value from the vector of  | 
10586  |  | ** new row values stored as part of the UPDATE or INSERT change and  | 
10587  |  | ** returns SQLITE_OK. If the change is an UPDATE and does not include  | 
10588  |  | ** a new value for the requested column, *ppValue is set to NULL and  | 
10589  |  | ** SQLITE_OK returned. The name of the function comes from the fact that  | 
10590  |  | ** this is similar to the "new.*" columns available to update or delete  | 
10591  |  | ** triggers.  | 
10592  |  | **  | 
10593  |  | ** If some other error occurs (e.g. an OOM condition), an SQLite error code  | 
10594  |  | ** is returned and *ppValue is set to NULL.  | 
10595  |  | */  | 
10596  |  | SQLITE_API int sqlite3changeset_new(  | 
10597  |  |   sqlite3_changeset_iter *pIter,  /* Changeset iterator */  | 
10598  |  |   int iVal,                       /* Column number */  | 
10599  |  |   sqlite3_value **ppValue         /* OUT: New value (or NULL pointer) */  | 
10600  |  | );  | 
10601  |  |  | 
10602  |  | /*  | 
10603  |  | ** CAPI3REF: Obtain Conflicting Row Values From A Changeset Iterator  | 
10604  |  | ** METHOD: sqlite3_changeset_iter  | 
10605  |  | **  | 
10606  |  | ** This function should only be used with iterator objects passed to a  | 
10607  |  | ** conflict-handler callback by [sqlite3changeset_apply()] with either  | 
10608  |  | ** [SQLITE_CHANGESET_DATA] or [SQLITE_CHANGESET_CONFLICT]. If this function  | 
10609  |  | ** is called on any other iterator, [SQLITE_MISUSE] is returned and *ppValue  | 
10610  |  | ** is set to NULL.  | 
10611  |  | **  | 
10612  |  | ** Argument iVal must be greater than or equal to 0, and less than the number  | 
10613  |  | ** of columns in the table affected by the current change. Otherwise,  | 
10614  |  | ** [SQLITE_RANGE] is returned and *ppValue is set to NULL.  | 
10615  |  | **  | 
10616  |  | ** If successful, this function sets *ppValue to point to a protected  | 
10617  |  | ** sqlite3_value object containing the iVal'th value from the  | 
10618  |  | ** "conflicting row" associated with the current conflict-handler callback  | 
10619  |  | ** and returns SQLITE_OK.  | 
10620  |  | **  | 
10621  |  | ** If some other error occurs (e.g. an OOM condition), an SQLite error code  | 
10622  |  | ** is returned and *ppValue is set to NULL.  | 
10623  |  | */  | 
10624  |  | SQLITE_API int sqlite3changeset_conflict(  | 
10625  |  |   sqlite3_changeset_iter *pIter,  /* Changeset iterator */  | 
10626  |  |   int iVal,                       /* Column number */  | 
10627  |  |   sqlite3_value **ppValue         /* OUT: Value from conflicting row */  | 
10628  |  | );  | 
10629  |  |  | 
10630  |  | /*  | 
10631  |  | ** CAPI3REF: Determine The Number Of Foreign Key Constraint Violations  | 
10632  |  | ** METHOD: sqlite3_changeset_iter  | 
10633  |  | **  | 
10634  |  | ** This function may only be called with an iterator passed to an  | 
10635  |  | ** SQLITE_CHANGESET_FOREIGN_KEY conflict handler callback. In this case  | 
10636  |  | ** it sets the output variable to the total number of known foreign key  | 
10637  |  | ** violations in the destination database and returns SQLITE_OK.  | 
10638  |  | **  | 
10639  |  | ** In all other cases this function returns SQLITE_MISUSE.  | 
10640  |  | */  | 
10641  |  | SQLITE_API int sqlite3changeset_fk_conflicts(  | 
10642  |  |   sqlite3_changeset_iter *pIter,  /* Changeset iterator */  | 
10643  |  |   int *pnOut                      /* OUT: Number of FK violations */  | 
10644  |  | );  | 
10645  |  |  | 
10646  |  |  | 
10647  |  | /*  | 
10648  |  | ** CAPI3REF: Finalize A Changeset Iterator  | 
10649  |  | ** METHOD: sqlite3_changeset_iter  | 
10650  |  | **  | 
10651  |  | ** This function is used to finalize an iterator allocated with  | 
10652  |  | ** [sqlite3changeset_start()].  | 
10653  |  | **  | 
10654  |  | ** This function should only be called on iterators created using the  | 
10655  |  | ** [sqlite3changeset_start()] function. If an application calls this  | 
10656  |  | ** function with an iterator passed to a conflict-handler by  | 
10657  |  | ** [sqlite3changeset_apply()], [SQLITE_MISUSE] is immediately returned and the  | 
10658  |  | ** call has no effect.  | 
10659  |  | **  | 
10660  |  | ** If an error was encountered within a call to an sqlite3changeset_xxx()  | 
10661  |  | ** function (for example an [SQLITE_CORRUPT] in [sqlite3changeset_next()] or an  | 
10662  |  | ** [SQLITE_NOMEM] in [sqlite3changeset_new()]) then an error code corresponding  | 
10663  |  | ** to that error is returned by this function. Otherwise, SQLITE_OK is  | 
10664  |  | ** returned. This is to allow the following pattern (pseudo-code):  | 
10665  |  | **  | 
10666  |  | ** <pre>  | 
10667  |  | **   sqlite3changeset_start();  | 
10668  |  | **   while( SQLITE_ROW==sqlite3changeset_next() ){ | 
10669  |  | **     // Do something with change.  | 
10670  |  | **   }  | 
10671  |  | **   rc = sqlite3changeset_finalize();  | 
10672  |  | **   if( rc!=SQLITE_OK ){ | 
10673  |  | **     // An error has occurred  | 
10674  |  | **   }  | 
10675  |  | ** </pre>  | 
10676  |  | */  | 
10677  |  | SQLITE_API int sqlite3changeset_finalize(sqlite3_changeset_iter *pIter);  | 
10678  |  |  | 
10679  |  | /*  | 
10680  |  | ** CAPI3REF: Invert A Changeset  | 
10681  |  | **  | 
10682  |  | ** This function is used to "invert" a changeset object. Applying an inverted  | 
10683  |  | ** changeset to a database reverses the effects of applying the uninverted  | 
10684  |  | ** changeset. Specifically:  | 
10685  |  | **  | 
10686  |  | ** <ul>  | 
10687  |  | **   <li> Each DELETE change is changed to an INSERT, and  | 
10688  |  | **   <li> Each INSERT change is changed to a DELETE, and  | 
10689  |  | **   <li> For each UPDATE change, the old.* and new.* values are exchanged.  | 
10690  |  | ** </ul>  | 
10691  |  | **  | 
10692  |  | ** This function does not change the order in which changes appear within  | 
10693  |  | ** the changeset. It merely reverses the sense of each individual change.  | 
10694  |  | **  | 
10695  |  | ** If successful, a pointer to a buffer containing the inverted changeset  | 
10696  |  | ** is stored in *ppOut, the size of the same buffer is stored in *pnOut, and  | 
10697  |  | ** SQLITE_OK is returned. If an error occurs, both *pnOut and *ppOut are  | 
10698  |  | ** zeroed and an SQLite error code returned.  | 
10699  |  | **  | 
10700  |  | ** It is the responsibility of the caller to eventually call sqlite3_free()  | 
10701  |  | ** on the *ppOut pointer to free the buffer allocation following a successful  | 
10702  |  | ** call to this function.  | 
10703  |  | **  | 
10704  |  | ** WARNING/TODO: This function currently assumes that the input is a valid  | 
10705  |  | ** changeset. If it is not, the results are undefined.  | 
10706  |  | */  | 
10707  |  | SQLITE_API int sqlite3changeset_invert(  | 
10708  |  |   int nIn, const void *pIn,       /* Input changeset */  | 
10709  |  |   int *pnOut, void **ppOut        /* OUT: Inverse of input */  | 
10710  |  | );  | 
10711  |  |  | 
10712  |  | /*  | 
10713  |  | ** CAPI3REF: Concatenate Two Changeset Objects  | 
10714  |  | **  | 
10715  |  | ** This function is used to concatenate two changesets, A and B, into a  | 
10716  |  | ** single changeset. The result is a changeset equivalent to applying  | 
10717  |  | ** changeset A followed by changeset B.  | 
10718  |  | **  | 
10719  |  | ** This function combines the two input changesets using an  | 
10720  |  | ** sqlite3_changegroup object. Calling it produces similar results as the  | 
10721  |  | ** following code fragment:  | 
10722  |  | **  | 
10723  |  | ** <pre>  | 
10724  |  | **   sqlite3_changegroup *pGrp;  | 
10725  |  | **   rc = sqlite3_changegroup_new(&pGrp);  | 
10726  |  | **   if( rc==SQLITE_OK ) rc = sqlite3changegroup_add(pGrp, nA, pA);  | 
10727  |  | **   if( rc==SQLITE_OK ) rc = sqlite3changegroup_add(pGrp, nB, pB);  | 
10728  |  | **   if( rc==SQLITE_OK ){ | 
10729  |  | **     rc = sqlite3changegroup_output(pGrp, pnOut, ppOut);  | 
10730  |  | **   }else{ | 
10731  |  | **     *ppOut = 0;  | 
10732  |  | **     *pnOut = 0;  | 
10733  |  | **   }  | 
10734  |  | ** </pre>  | 
10735  |  | **  | 
10736  |  | ** Refer to the sqlite3_changegroup documentation below for details.  | 
10737  |  | */  | 
10738  |  | SQLITE_API int sqlite3changeset_concat(  | 
10739  |  |   int nA,                         /* Number of bytes in buffer pA */  | 
10740  |  |   void *pA,                       /* Pointer to buffer containing changeset A */  | 
10741  |  |   int nB,                         /* Number of bytes in buffer pB */  | 
10742  |  |   void *pB,                       /* Pointer to buffer containing changeset B */  | 
10743  |  |   int *pnOut,                     /* OUT: Number of bytes in output changeset */  | 
10744  |  |   void **ppOut                    /* OUT: Buffer containing output changeset */  | 
10745  |  | );  | 
10746  |  |  | 
10747  |  |  | 
10748  |  | /*  | 
10749  |  | ** CAPI3REF: Changegroup Handle  | 
10750  |  | **  | 
10751  |  | ** A changegroup is an object used to combine two or more  | 
10752  |  | ** [changesets] or [patchsets]  | 
10753  |  | */  | 
10754  |  | typedef struct sqlite3_changegroup sqlite3_changegroup;  | 
10755  |  |  | 
10756  |  | /*  | 
10757  |  | ** CAPI3REF: Create A New Changegroup Object  | 
10758  |  | ** CONSTRUCTOR: sqlite3_changegroup  | 
10759  |  | **  | 
10760  |  | ** An sqlite3_changegroup object is used to combine two or more changesets  | 
10761  |  | ** (or patchsets) into a single changeset (or patchset). A single changegroup  | 
10762  |  | ** object may combine changesets or patchsets, but not both. The output is  | 
10763  |  | ** always in the same format as the input.  | 
10764  |  | **  | 
10765  |  | ** If successful, this function returns SQLITE_OK and populates (*pp) with  | 
10766  |  | ** a pointer to a new sqlite3_changegroup object before returning. The caller  | 
10767  |  | ** should eventually free the returned object using a call to  | 
10768  |  | ** sqlite3changegroup_delete(). If an error occurs, an SQLite error code  | 
10769  |  | ** (i.e. SQLITE_NOMEM) is returned and *pp is set to NULL.  | 
10770  |  | **  | 
10771  |  | ** The usual usage pattern for an sqlite3_changegroup object is as follows:  | 
10772  |  | **  | 
10773  |  | ** <ul>  | 
10774  |  | **   <li> It is created using a call to sqlite3changegroup_new().  | 
10775  |  | **  | 
10776  |  | **   <li> Zero or more changesets (or patchsets) are added to the object  | 
10777  |  | **        by calling sqlite3changegroup_add().  | 
10778  |  | **  | 
10779  |  | **   <li> The result of combining all input changesets together is obtained  | 
10780  |  | **        by the application via a call to sqlite3changegroup_output().  | 
10781  |  | **  | 
10782  |  | **   <li> The object is deleted using a call to sqlite3changegroup_delete().  | 
10783  |  | ** </ul>  | 
10784  |  | **  | 
10785  |  | ** Any number of calls to add() and output() may be made between the calls to  | 
10786  |  | ** new() and delete(), and in any order.  | 
10787  |  | **  | 
10788  |  | ** As well as the regular sqlite3changegroup_add() and  | 
10789  |  | ** sqlite3changegroup_output() functions, also available are the streaming  | 
10790  |  | ** versions sqlite3changegroup_add_strm() and sqlite3changegroup_output_strm().  | 
10791  |  | */  | 
10792  |  | SQLITE_API int sqlite3changegroup_new(sqlite3_changegroup **pp);  | 
10793  |  |  | 
10794  |  | /*  | 
10795  |  | ** CAPI3REF: Add A Changeset To A Changegroup  | 
10796  |  | ** METHOD: sqlite3_changegroup  | 
10797  |  | **  | 
10798  |  | ** Add all changes within the changeset (or patchset) in buffer pData (size  | 
10799  |  | ** nData bytes) to the changegroup.  | 
10800  |  | **  | 
10801  |  | ** If the buffer contains a patchset, then all prior calls to this function  | 
10802  |  | ** on the same changegroup object must also have specified patchsets. Or, if  | 
10803  |  | ** the buffer contains a changeset, so must have the earlier calls to this  | 
10804  |  | ** function. Otherwise, SQLITE_ERROR is returned and no changes are added  | 
10805  |  | ** to the changegroup.  | 
10806  |  | **  | 
10807  |  | ** Rows within the changeset and changegroup are identified by the values in  | 
10808  |  | ** their PRIMARY KEY columns. A change in the changeset is considered to  | 
10809  |  | ** apply to the same row as a change already present in the changegroup if  | 
10810  |  | ** the two rows have the same primary key.  | 
10811  |  | **  | 
10812  |  | ** Changes to rows that do not already appear in the changegroup are  | 
10813  |  | ** simply copied into it. Or, if both the new changeset and the changegroup  | 
10814  |  | ** contain changes that apply to a single row, the final contents of the  | 
10815  |  | ** changegroup depends on the type of each change, as follows:  | 
10816  |  | **  | 
10817  |  | ** <table border=1 style="margin-left:8ex;margin-right:8ex">  | 
10818  |  | **   <tr><th style="white-space:pre">Existing Change  </th>  | 
10819  |  | **       <th style="white-space:pre">New Change       </th>  | 
10820  |  | **       <th>Output Change  | 
10821  |  | **   <tr><td>INSERT <td>INSERT <td>  | 
10822  |  | **       The new change is ignored. This case does not occur if the new  | 
10823  |  | **       changeset was recorded immediately after the changesets already  | 
10824  |  | **       added to the changegroup.  | 
10825  |  | **   <tr><td>INSERT <td>UPDATE <td>  | 
10826  |  | **       The INSERT change remains in the changegroup. The values in the  | 
10827  |  | **       INSERT change are modified as if the row was inserted by the  | 
10828  |  | **       existing change and then updated according to the new change.  | 
10829  |  | **   <tr><td>INSERT <td>DELETE <td>  | 
10830  |  | **       The existing INSERT is removed from the changegroup. The DELETE is  | 
10831  |  | **       not added.  | 
10832  |  | **   <tr><td>UPDATE <td>INSERT <td>  | 
10833  |  | **       The new change is ignored. This case does not occur if the new  | 
10834  |  | **       changeset was recorded immediately after the changesets already  | 
10835  |  | **       added to the changegroup.  | 
10836  |  | **   <tr><td>UPDATE <td>UPDATE <td>  | 
10837  |  | **       The existing UPDATE remains within the changegroup. It is amended  | 
10838  |  | **       so that the accompanying values are as if the row was updated once  | 
10839  |  | **       by the existing change and then again by the new change.  | 
10840  |  | **   <tr><td>UPDATE <td>DELETE <td>  | 
10841  |  | **       The existing UPDATE is replaced by the new DELETE within the  | 
10842  |  | **       changegroup.  | 
10843  |  | **   <tr><td>DELETE <td>INSERT <td>  | 
10844  |  | **       If one or more of the column values in the row inserted by the  | 
10845  |  | **       new change differ from those in the row deleted by the existing  | 
10846  |  | **       change, the existing DELETE is replaced by an UPDATE within the  | 
10847  |  | **       changegroup. Otherwise, if the inserted row is exactly the same  | 
10848  |  | **       as the deleted row, the existing DELETE is simply discarded.  | 
10849  |  | **   <tr><td>DELETE <td>UPDATE <td>  | 
10850  |  | **       The new change is ignored. This case does not occur if the new  | 
10851  |  | **       changeset was recorded immediately after the changesets already  | 
10852  |  | **       added to the changegroup.  | 
10853  |  | **   <tr><td>DELETE <td>DELETE <td>  | 
10854  |  | **       The new change is ignored. This case does not occur if the new  | 
10855  |  | **       changeset was recorded immediately after the changesets already  | 
10856  |  | **       added to the changegroup.  | 
10857  |  | ** </table>  | 
10858  |  | **  | 
10859  |  | ** If the new changeset contains changes to a table that is already present  | 
10860  |  | ** in the changegroup, then the number of columns and the position of the  | 
10861  |  | ** primary key columns for the table must be consistent. If this is not the  | 
10862  |  | ** case, this function fails with SQLITE_SCHEMA. If the input changeset  | 
10863  |  | ** appears to be corrupt and the corruption is detected, SQLITE_CORRUPT is  | 
10864  |  | ** returned. Or, if an out-of-memory condition occurs during processing, this  | 
10865  |  | ** function returns SQLITE_NOMEM. In all cases, if an error occurs the state  | 
10866  |  | ** of the final contents of the changegroup is undefined.  | 
10867  |  | **  | 
10868  |  | ** If no error occurs, SQLITE_OK is returned.  | 
10869  |  | */  | 
10870  |  | SQLITE_API int sqlite3changegroup_add(sqlite3_changegroup*, int nData, void *pData);  | 
10871  |  |  | 
10872  |  | /*  | 
10873  |  | ** CAPI3REF: Obtain A Composite Changeset From A Changegroup  | 
10874  |  | ** METHOD: sqlite3_changegroup  | 
10875  |  | **  | 
10876  |  | ** Obtain a buffer containing a changeset (or patchset) representing the  | 
10877  |  | ** current contents of the changegroup. If the inputs to the changegroup  | 
10878  |  | ** were themselves changesets, the output is a changeset. Or, if the  | 
10879  |  | ** inputs were patchsets, the output is also a patchset.  | 
10880  |  | **  | 
10881  |  | ** As with the output of the sqlite3session_changeset() and  | 
10882  |  | ** sqlite3session_patchset() functions, all changes related to a single  | 
10883  |  | ** table are grouped together in the output of this function. Tables appear  | 
10884  |  | ** in the same order as for the very first changeset added to the changegroup.  | 
10885  |  | ** If the second or subsequent changesets added to the changegroup contain  | 
10886  |  | ** changes for tables that do not appear in the first changeset, they are  | 
10887  |  | ** appended onto the end of the output changeset, again in the order in  | 
10888  |  | ** which they are first encountered.  | 
10889  |  | **  | 
10890  |  | ** If an error occurs, an SQLite error code is returned and the output  | 
10891  |  | ** variables (*pnData) and (*ppData) are set to 0. Otherwise, SQLITE_OK  | 
10892  |  | ** is returned and the output variables are set to the size of and a  | 
10893  |  | ** pointer to the output buffer, respectively. In this case it is the  | 
10894  |  | ** responsibility of the caller to eventually free the buffer using a  | 
10895  |  | ** call to sqlite3_free().  | 
10896  |  | */  | 
10897  |  | SQLITE_API int sqlite3changegroup_output(  | 
10898  |  |   sqlite3_changegroup*,  | 
10899  |  |   int *pnData,                    /* OUT: Size of output buffer in bytes */  | 
10900  |  |   void **ppData                   /* OUT: Pointer to output buffer */  | 
10901  |  | );  | 
10902  |  |  | 
10903  |  | /*  | 
10904  |  | ** CAPI3REF: Delete A Changegroup Object  | 
10905  |  | ** DESTRUCTOR: sqlite3_changegroup  | 
10906  |  | */  | 
10907  |  | SQLITE_API void sqlite3changegroup_delete(sqlite3_changegroup*);  | 
10908  |  |  | 
10909  |  | /*  | 
10910  |  | ** CAPI3REF: Apply A Changeset To A Database  | 
10911  |  | **  | 
10912  |  | ** Apply a changeset or patchset to a database. These functions attempt to  | 
10913  |  | ** update the "main" database attached to handle db with the changes found in  | 
10914  |  | ** the changeset passed via the second and third arguments.  | 
10915  |  | **  | 
10916  |  | ** The fourth argument (xFilter) passed to these functions is the "filter  | 
10917  |  | ** callback". If it is not NULL, then for each table affected by at least one  | 
10918  |  | ** change in the changeset, the filter callback is invoked with  | 
10919  |  | ** the table name as the second argument, and a copy of the context pointer  | 
10920  |  | ** passed as the sixth argument as the first. If the "filter callback"  | 
10921  |  | ** returns zero, then no attempt is made to apply any changes to the table.  | 
10922  |  | ** Otherwise, if the return value is non-zero or the xFilter argument to  | 
10923  |  | ** is NULL, all changes related to the table are attempted.  | 
10924  |  | **  | 
10925  |  | ** For each table that is not excluded by the filter callback, this function  | 
10926  |  | ** tests that the target database contains a compatible table. A table is  | 
10927  |  | ** considered compatible if all of the following are true:  | 
10928  |  | **  | 
10929  |  | ** <ul>  | 
10930  |  | **   <li> The table has the same name as the name recorded in the  | 
10931  |  | **        changeset, and  | 
10932  |  | **   <li> The table has at least as many columns as recorded in the  | 
10933  |  | **        changeset, and  | 
10934  |  | **   <li> The table has primary key columns in the same position as  | 
10935  |  | **        recorded in the changeset.  | 
10936  |  | ** </ul>  | 
10937  |  | **  | 
10938  |  | ** If there is no compatible table, it is not an error, but none of the  | 
10939  |  | ** changes associated with the table are applied. A warning message is issued  | 
10940  |  | ** via the sqlite3_log() mechanism with the error code SQLITE_SCHEMA. At most  | 
10941  |  | ** one such warning is issued for each table in the changeset.  | 
10942  |  | **  | 
10943  |  | ** For each change for which there is a compatible table, an attempt is made  | 
10944  |  | ** to modify the table contents according to the UPDATE, INSERT or DELETE  | 
10945  |  | ** change. If a change cannot be applied cleanly, the conflict handler  | 
10946  |  | ** function passed as the fifth argument to sqlite3changeset_apply() may be  | 
10947  |  | ** invoked. A description of exactly when the conflict handler is invoked for  | 
10948  |  | ** each type of change is below.  | 
10949  |  | **  | 
10950  |  | ** Unlike the xFilter argument, xConflict may not be passed NULL. The results  | 
10951  |  | ** of passing anything other than a valid function pointer as the xConflict  | 
10952  |  | ** argument are undefined.  | 
10953  |  | **  | 
10954  |  | ** Each time the conflict handler function is invoked, it must return one  | 
10955  |  | ** of [SQLITE_CHANGESET_OMIT], [SQLITE_CHANGESET_ABORT] or  | 
10956  |  | ** [SQLITE_CHANGESET_REPLACE]. SQLITE_CHANGESET_REPLACE may only be returned  | 
10957  |  | ** if the second argument passed to the conflict handler is either  | 
10958  |  | ** SQLITE_CHANGESET_DATA or SQLITE_CHANGESET_CONFLICT. If the conflict-handler  | 
10959  |  | ** returns an illegal value, any changes already made are rolled back and  | 
10960  |  | ** the call to sqlite3changeset_apply() returns SQLITE_MISUSE. Different  | 
10961  |  | ** actions are taken by sqlite3changeset_apply() depending on the value  | 
10962  |  | ** returned by each invocation of the conflict-handler function. Refer to  | 
10963  |  | ** the documentation for the three  | 
10964  |  | ** [SQLITE_CHANGESET_OMIT|available return values] for details.  | 
10965  |  | **  | 
10966  |  | ** <dl>  | 
10967  |  | ** <dt>DELETE Changes<dd>  | 
10968  |  | **   For each DELETE change, the function checks if the target database  | 
10969  |  | **   contains a row with the same primary key value (or values) as the  | 
10970  |  | **   original row values stored in the changeset. If it does, and the values  | 
10971  |  | **   stored in all non-primary key columns also match the values stored in  | 
10972  |  | **   the changeset the row is deleted from the target database.  | 
10973  |  | **  | 
10974  |  | **   If a row with matching primary key values is found, but one or more of  | 
10975  |  | **   the non-primary key fields contains a value different from the original  | 
10976  |  | **   row value stored in the changeset, the conflict-handler function is  | 
10977  |  | **   invoked with [SQLITE_CHANGESET_DATA] as the second argument. If the  | 
10978  |  | **   database table has more columns than are recorded in the changeset,  | 
10979  |  | **   only the values of those non-primary key fields are compared against  | 
10980  |  | **   the current database contents - any trailing database table columns  | 
10981  |  | **   are ignored.  | 
10982  |  | **  | 
10983  |  | **   If no row with matching primary key values is found in the database,  | 
10984  |  | **   the conflict-handler function is invoked with [SQLITE_CHANGESET_NOTFOUND]  | 
10985  |  | **   passed as the second argument.  | 
10986  |  | **  | 
10987  |  | **   If the DELETE operation is attempted, but SQLite returns SQLITE_CONSTRAINT  | 
10988  |  | **   (which can only happen if a foreign key constraint is violated), the  | 
10989  |  | **   conflict-handler function is invoked with [SQLITE_CHANGESET_CONSTRAINT]  | 
10990  |  | **   passed as the second argument. This includes the case where the DELETE  | 
10991  |  | **   operation is attempted because an earlier call to the conflict handler  | 
10992  |  | **   function returned [SQLITE_CHANGESET_REPLACE].  | 
10993  |  | **  | 
10994  |  | ** <dt>INSERT Changes<dd>  | 
10995  |  | **   For each INSERT change, an attempt is made to insert the new row into  | 
10996  |  | **   the database. If the changeset row contains fewer fields than the  | 
10997  |  | **   database table, the trailing fields are populated with their default  | 
10998  |  | **   values.  | 
10999  |  | **  | 
11000  |  | **   If the attempt to insert the row fails because the database already  | 
11001  |  | **   contains a row with the same primary key values, the conflict handler  | 
11002  |  | **   function is invoked with the second argument set to  | 
11003  |  | **   [SQLITE_CHANGESET_CONFLICT].  | 
11004  |  | **  | 
11005  |  | **   If the attempt to insert the row fails because of some other constraint  | 
11006  |  | **   violation (e.g. NOT NULL or UNIQUE), the conflict handler function is  | 
11007  |  | **   invoked with the second argument set to [SQLITE_CHANGESET_CONSTRAINT].  | 
11008  |  | **   This includes the case where the INSERT operation is re-attempted because  | 
11009  |  | **   an earlier call to the conflict handler function returned  | 
11010  |  | **   [SQLITE_CHANGESET_REPLACE].  | 
11011  |  | **  | 
11012  |  | ** <dt>UPDATE Changes<dd>  | 
11013  |  | **   For each UPDATE change, the function checks if the target database  | 
11014  |  | **   contains a row with the same primary key value (or values) as the  | 
11015  |  | **   original row values stored in the changeset. If it does, and the values  | 
11016  |  | **   stored in all modified non-primary key columns also match the values  | 
11017  |  | **   stored in the changeset the row is updated within the target database.  | 
11018  |  | **  | 
11019  |  | **   If a row with matching primary key values is found, but one or more of  | 
11020  |  | **   the modified non-primary key fields contains a value different from an  | 
11021  |  | **   original row value stored in the changeset, the conflict-handler function  | 
11022  |  | **   is invoked with [SQLITE_CHANGESET_DATA] as the second argument. Since  | 
11023  |  | **   UPDATE changes only contain values for non-primary key fields that are  | 
11024  |  | **   to be modified, only those fields need to match the original values to  | 
11025  |  | **   avoid the SQLITE_CHANGESET_DATA conflict-handler callback.  | 
11026  |  | **  | 
11027  |  | **   If no row with matching primary key values is found in the database,  | 
11028  |  | **   the conflict-handler function is invoked with [SQLITE_CHANGESET_NOTFOUND]  | 
11029  |  | **   passed as the second argument.  | 
11030  |  | **  | 
11031  |  | **   If the UPDATE operation is attempted, but SQLite returns  | 
11032  |  | **   SQLITE_CONSTRAINT, the conflict-handler function is invoked with  | 
11033  |  | **   [SQLITE_CHANGESET_CONSTRAINT] passed as the second argument.  | 
11034  |  | **   This includes the case where the UPDATE operation is attempted after  | 
11035  |  | **   an earlier call to the conflict handler function returned  | 
11036  |  | **   [SQLITE_CHANGESET_REPLACE].  | 
11037  |  | ** </dl>  | 
11038  |  | **  | 
11039  |  | ** It is safe to execute SQL statements, including those that write to the  | 
11040  |  | ** table that the callback related to, from within the xConflict callback.  | 
11041  |  | ** This can be used to further customize the application's conflict  | 
11042  |  | ** resolution strategy.  | 
11043  |  | **  | 
11044  |  | ** All changes made by these functions are enclosed in a savepoint transaction.  | 
11045  |  | ** If any other error (aside from a constraint failure when attempting to  | 
11046  |  | ** write to the target database) occurs, then the savepoint transaction is  | 
11047  |  | ** rolled back, restoring the target database to its original state, and an  | 
11048  |  | ** SQLite error code returned.  | 
11049  |  | **  | 
11050  |  | ** If the output parameters (ppRebase) and (pnRebase) are non-NULL and  | 
11051  |  | ** the input is a changeset (not a patchset), then sqlite3changeset_apply_v2()  | 
11052  |  | ** may set (*ppRebase) to point to a "rebase" that may be used with the  | 
11053  |  | ** sqlite3_rebaser APIs buffer before returning. In this case (*pnRebase)  | 
11054  |  | ** is set to the size of the buffer in bytes. It is the responsibility of the  | 
11055  |  | ** caller to eventually free any such buffer using sqlite3_free(). The buffer  | 
11056  |  | ** is only allocated and populated if one or more conflicts were encountered  | 
11057  |  | ** while applying the patchset. See comments surrounding the sqlite3_rebaser  | 
11058  |  | ** APIs for further details.  | 
11059  |  | **  | 
11060  |  | ** The behavior of sqlite3changeset_apply_v2() and its streaming equivalent  | 
11061  |  | ** may be modified by passing a combination of  | 
11062  |  | ** [SQLITE_CHANGESETAPPLY_NOSAVEPOINT | supported flags] as the 9th parameter.  | 
11063  |  | **  | 
11064  |  | ** Note that the sqlite3changeset_apply_v2() API is still <b>experimental</b>  | 
11065  |  | ** and therefore subject to change.  | 
11066  |  | */  | 
11067  |  | SQLITE_API int sqlite3changeset_apply(  | 
11068  |  |   sqlite3 *db,                    /* Apply change to "main" db of this handle */  | 
11069  |  |   int nChangeset,                 /* Size of changeset in bytes */  | 
11070  |  |   void *pChangeset,               /* Changeset blob */  | 
11071  |  |   int(*xFilter)(  | 
11072  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11073  |  |     const char *zTab              /* Table name */  | 
11074  |  |   ),  | 
11075  |  |   int(*xConflict)(  | 
11076  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11077  |  |     int eConflict,                /* DATA, MISSING, CONFLICT, CONSTRAINT */  | 
11078  |  |     sqlite3_changeset_iter *p     /* Handle describing change and conflict */  | 
11079  |  |   ),  | 
11080  |  |   void *pCtx                      /* First argument passed to xConflict */  | 
11081  |  | );  | 
11082  |  | SQLITE_API int sqlite3changeset_apply_v2(  | 
11083  |  |   sqlite3 *db,                    /* Apply change to "main" db of this handle */  | 
11084  |  |   int nChangeset,                 /* Size of changeset in bytes */  | 
11085  |  |   void *pChangeset,               /* Changeset blob */  | 
11086  |  |   int(*xFilter)(  | 
11087  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11088  |  |     const char *zTab              /* Table name */  | 
11089  |  |   ),  | 
11090  |  |   int(*xConflict)(  | 
11091  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11092  |  |     int eConflict,                /* DATA, MISSING, CONFLICT, CONSTRAINT */  | 
11093  |  |     sqlite3_changeset_iter *p     /* Handle describing change and conflict */  | 
11094  |  |   ),  | 
11095  |  |   void *pCtx,                     /* First argument passed to xConflict */  | 
11096  |  |   void **ppRebase, int *pnRebase, /* OUT: Rebase data */  | 
11097  |  |   int flags                       /* SESSION_CHANGESETAPPLY_* flags */  | 
11098  |  | );  | 
11099  |  |  | 
11100  |  | /*  | 
11101  |  | ** CAPI3REF: Flags for sqlite3changeset_apply_v2  | 
11102  |  | **  | 
11103  |  | ** The following flags may passed via the 9th parameter to  | 
11104  |  | ** [sqlite3changeset_apply_v2] and [sqlite3changeset_apply_v2_strm]:  | 
11105  |  | **  | 
11106  |  | ** <dl>  | 
11107  |  | ** <dt>SQLITE_CHANGESETAPPLY_NOSAVEPOINT <dd>  | 
11108  |  | **   Usually, the sessions module encloses all operations performed by  | 
11109  |  | **   a single call to apply_v2() or apply_v2_strm() in a [SAVEPOINT]. The  | 
11110  |  | **   SAVEPOINT is committed if the changeset or patchset is successfully  | 
11111  |  | **   applied, or rolled back if an error occurs. Specifying this flag  | 
11112  |  | **   causes the sessions module to omit this savepoint. In this case, if the  | 
11113  |  | **   caller has an open transaction or savepoint when apply_v2() is called,  | 
11114  |  | **   it may revert the partially applied changeset by rolling it back.  | 
11115  |  | **  | 
11116  |  | ** <dt>SQLITE_CHANGESETAPPLY_INVERT <dd>  | 
11117  |  | **   Invert the changeset before applying it. This is equivalent to inverting  | 
11118  |  | **   a changeset using sqlite3changeset_invert() before applying it. It is  | 
11119  |  | **   an error to specify this flag with a patchset.  | 
11120  |  | */  | 
11121  |  | #define SQLITE_CHANGESETAPPLY_NOSAVEPOINT   0x0001  | 
11122  |  | #define SQLITE_CHANGESETAPPLY_INVERT        0x0002  | 
11123  |  |  | 
11124  |  | /*  | 
11125  |  | ** CAPI3REF: Constants Passed To The Conflict Handler  | 
11126  |  | **  | 
11127  |  | ** Values that may be passed as the second argument to a conflict-handler.  | 
11128  |  | **  | 
11129  |  | ** <dl>  | 
11130  |  | ** <dt>SQLITE_CHANGESET_DATA<dd>  | 
11131  |  | **   The conflict handler is invoked with CHANGESET_DATA as the second argument  | 
11132  |  | **   when processing a DELETE or UPDATE change if a row with the required  | 
11133  |  | **   PRIMARY KEY fields is present in the database, but one or more other  | 
11134  |  | **   (non primary-key) fields modified by the update do not contain the  | 
11135  |  | **   expected "before" values.  | 
11136  |  | **  | 
11137  |  | **   The conflicting row, in this case, is the database row with the matching  | 
11138  |  | **   primary key.  | 
11139  |  | **  | 
11140  |  | ** <dt>SQLITE_CHANGESET_NOTFOUND<dd>  | 
11141  |  | **   The conflict handler is invoked with CHANGESET_NOTFOUND as the second  | 
11142  |  | **   argument when processing a DELETE or UPDATE change if a row with the  | 
11143  |  | **   required PRIMARY KEY fields is not present in the database.  | 
11144  |  | **  | 
11145  |  | **   There is no conflicting row in this case. The results of invoking the  | 
11146  |  | **   sqlite3changeset_conflict() API are undefined.  | 
11147  |  | **  | 
11148  |  | ** <dt>SQLITE_CHANGESET_CONFLICT<dd>  | 
11149  |  | **   CHANGESET_CONFLICT is passed as the second argument to the conflict  | 
11150  |  | **   handler while processing an INSERT change if the operation would result  | 
11151  |  | **   in duplicate primary key values.  | 
11152  |  | **  | 
11153  |  | **   The conflicting row in this case is the database row with the matching  | 
11154  |  | **   primary key.  | 
11155  |  | **  | 
11156  |  | ** <dt>SQLITE_CHANGESET_FOREIGN_KEY<dd>  | 
11157  |  | **   If foreign key handling is enabled, and applying a changeset leaves the  | 
11158  |  | **   database in a state containing foreign key violations, the conflict  | 
11159  |  | **   handler is invoked with CHANGESET_FOREIGN_KEY as the second argument  | 
11160  |  | **   exactly once before the changeset is committed. If the conflict handler  | 
11161  |  | **   returns CHANGESET_OMIT, the changes, including those that caused the  | 
11162  |  | **   foreign key constraint violation, are committed. Or, if it returns  | 
11163  |  | **   CHANGESET_ABORT, the changeset is rolled back.  | 
11164  |  | **  | 
11165  |  | **   No current or conflicting row information is provided. The only function  | 
11166  |  | **   it is possible to call on the supplied sqlite3_changeset_iter handle  | 
11167  |  | **   is sqlite3changeset_fk_conflicts().  | 
11168  |  | **  | 
11169  |  | ** <dt>SQLITE_CHANGESET_CONSTRAINT<dd>  | 
11170  |  | **   If any other constraint violation occurs while applying a change (i.e.  | 
11171  |  | **   a UNIQUE, CHECK or NOT NULL constraint), the conflict handler is  | 
11172  |  | **   invoked with CHANGESET_CONSTRAINT as the second argument.  | 
11173  |  | **  | 
11174  |  | **   There is no conflicting row in this case. The results of invoking the  | 
11175  |  | **   sqlite3changeset_conflict() API are undefined.  | 
11176  |  | **  | 
11177  |  | ** </dl>  | 
11178  |  | */  | 
11179  |  | #define SQLITE_CHANGESET_DATA        1  | 
11180  |  | #define SQLITE_CHANGESET_NOTFOUND    2  | 
11181  |  | #define SQLITE_CHANGESET_CONFLICT    3  | 
11182  |  | #define SQLITE_CHANGESET_CONSTRAINT  4  | 
11183  |  | #define SQLITE_CHANGESET_FOREIGN_KEY 5  | 
11184  |  |  | 
11185  |  | /*  | 
11186  |  | ** CAPI3REF: Constants Returned By The Conflict Handler  | 
11187  |  | **  | 
11188  |  | ** A conflict handler callback must return one of the following three values.  | 
11189  |  | **  | 
11190  |  | ** <dl>  | 
11191  |  | ** <dt>SQLITE_CHANGESET_OMIT<dd>  | 
11192  |  | **   If a conflict handler returns this value no special action is taken. The  | 
11193  |  | **   change that caused the conflict is not applied. The session module  | 
11194  |  | **   continues to the next change in the changeset.  | 
11195  |  | **  | 
11196  |  | ** <dt>SQLITE_CHANGESET_REPLACE<dd>  | 
11197  |  | **   This value may only be returned if the second argument to the conflict  | 
11198  |  | **   handler was SQLITE_CHANGESET_DATA or SQLITE_CHANGESET_CONFLICT. If this  | 
11199  |  | **   is not the case, any changes applied so far are rolled back and the  | 
11200  |  | **   call to sqlite3changeset_apply() returns SQLITE_MISUSE.  | 
11201  |  | **  | 
11202  |  | **   If CHANGESET_REPLACE is returned by an SQLITE_CHANGESET_DATA conflict  | 
11203  |  | **   handler, then the conflicting row is either updated or deleted, depending  | 
11204  |  | **   on the type of change.  | 
11205  |  | **  | 
11206  |  | **   If CHANGESET_REPLACE is returned by an SQLITE_CHANGESET_CONFLICT conflict  | 
11207  |  | **   handler, then the conflicting row is removed from the database and a  | 
11208  |  | **   second attempt to apply the change is made. If this second attempt fails,  | 
11209  |  | **   the original row is restored to the database before continuing.  | 
11210  |  | **  | 
11211  |  | ** <dt>SQLITE_CHANGESET_ABORT<dd>  | 
11212  |  | **   If this value is returned, any changes applied so far are rolled back  | 
11213  |  | **   and the call to sqlite3changeset_apply() returns SQLITE_ABORT.  | 
11214  |  | ** </dl>  | 
11215  |  | */  | 
11216  |  | #define SQLITE_CHANGESET_OMIT       0  | 
11217  |  | #define SQLITE_CHANGESET_REPLACE    1  | 
11218  |  | #define SQLITE_CHANGESET_ABORT      2  | 
11219  |  |  | 
11220  |  | /*  | 
11221  |  | ** CAPI3REF: Rebasing changesets  | 
11222  |  | ** EXPERIMENTAL  | 
11223  |  | **  | 
11224  |  | ** Suppose there is a site hosting a database in state S0. And that  | 
11225  |  | ** modifications are made that move that database to state S1 and a  | 
11226  |  | ** changeset recorded (the "local" changeset). Then, a changeset based  | 
11227  |  | ** on S0 is received from another site (the "remote" changeset) and  | 
11228  |  | ** applied to the database. The database is then in state  | 
11229  |  | ** (S1+"remote"), where the exact state depends on any conflict  | 
11230  |  | ** resolution decisions (OMIT or REPLACE) made while applying "remote".  | 
11231  |  | ** Rebasing a changeset is to update it to take those conflict  | 
11232  |  | ** resolution decisions into account, so that the same conflicts  | 
11233  |  | ** do not have to be resolved elsewhere in the network.  | 
11234  |  | **  | 
11235  |  | ** For example, if both the local and remote changesets contain an  | 
11236  |  | ** INSERT of the same key on "CREATE TABLE t1(a PRIMARY KEY, b)":  | 
11237  |  | **  | 
11238  |  | **   local:  INSERT INTO t1 VALUES(1, 'v1');  | 
11239  |  | **   remote: INSERT INTO t1 VALUES(1, 'v2');  | 
11240  |  | **  | 
11241  |  | ** and the conflict resolution is REPLACE, then the INSERT change is  | 
11242  |  | ** removed from the local changeset (it was overridden). Or, if the  | 
11243  |  | ** conflict resolution was "OMIT", then the local changeset is modified  | 
11244  |  | ** to instead contain:  | 
11245  |  | **  | 
11246  |  | **           UPDATE t1 SET b = 'v2' WHERE a=1;  | 
11247  |  | **  | 
11248  |  | ** Changes within the local changeset are rebased as follows:  | 
11249  |  | **  | 
11250  |  | ** <dl>  | 
11251  |  | ** <dt>Local INSERT<dd>  | 
11252  |  | **   This may only conflict with a remote INSERT. If the conflict  | 
11253  |  | **   resolution was OMIT, then add an UPDATE change to the rebased  | 
11254  |  | **   changeset. Or, if the conflict resolution was REPLACE, add  | 
11255  |  | **   nothing to the rebased changeset.  | 
11256  |  | **  | 
11257  |  | ** <dt>Local DELETE<dd>  | 
11258  |  | **   This may conflict with a remote UPDATE or DELETE. In both cases the  | 
11259  |  | **   only possible resolution is OMIT. If the remote operation was a  | 
11260  |  | **   DELETE, then add no change to the rebased changeset. If the remote  | 
11261  |  | **   operation was an UPDATE, then the old.* fields of change are updated  | 
11262  |  | **   to reflect the new.* values in the UPDATE.  | 
11263  |  | **  | 
11264  |  | ** <dt>Local UPDATE<dd>  | 
11265  |  | **   This may conflict with a remote UPDATE or DELETE. If it conflicts  | 
11266  |  | **   with a DELETE, and the conflict resolution was OMIT, then the update  | 
11267  |  | **   is changed into an INSERT. Any undefined values in the new.* record  | 
11268  |  | **   from the update change are filled in using the old.* values from  | 
11269  |  | **   the conflicting DELETE. Or, if the conflict resolution was REPLACE,  | 
11270  |  | **   the UPDATE change is simply omitted from the rebased changeset.  | 
11271  |  | **  | 
11272  |  | **   If conflict is with a remote UPDATE and the resolution is OMIT, then  | 
11273  |  | **   the old.* values are rebased using the new.* values in the remote  | 
11274  |  | **   change. Or, if the resolution is REPLACE, then the change is copied  | 
11275  |  | **   into the rebased changeset with updates to columns also updated by  | 
11276  |  | **   the conflicting remote UPDATE removed. If this means no columns would  | 
11277  |  | **   be updated, the change is omitted.  | 
11278  |  | ** </dl>  | 
11279  |  | **  | 
11280  |  | ** A local change may be rebased against multiple remote changes  | 
11281  |  | ** simultaneously. If a single key is modified by multiple remote  | 
11282  |  | ** changesets, they are combined as follows before the local changeset  | 
11283  |  | ** is rebased:  | 
11284  |  | **  | 
11285  |  | ** <ul>  | 
11286  |  | **    <li> If there has been one or more REPLACE resolutions on a  | 
11287  |  | **         key, it is rebased according to a REPLACE.  | 
11288  |  | **  | 
11289  |  | **    <li> If there have been no REPLACE resolutions on a key, then  | 
11290  |  | **         the local changeset is rebased according to the most recent  | 
11291  |  | **         of the OMIT resolutions.  | 
11292  |  | ** </ul>  | 
11293  |  | **  | 
11294  |  | ** Note that conflict resolutions from multiple remote changesets are  | 
11295  |  | ** combined on a per-field basis, not per-row. This means that in the  | 
11296  |  | ** case of multiple remote UPDATE operations, some fields of a single  | 
11297  |  | ** local change may be rebased for REPLACE while others are rebased for  | 
11298  |  | ** OMIT.  | 
11299  |  | **  | 
11300  |  | ** In order to rebase a local changeset, the remote changeset must first  | 
11301  |  | ** be applied to the local database using sqlite3changeset_apply_v2() and  | 
11302  |  | ** the buffer of rebase information captured. Then:  | 
11303  |  | **  | 
11304  |  | ** <ol>  | 
11305  |  | **   <li> An sqlite3_rebaser object is created by calling  | 
11306  |  | **        sqlite3rebaser_create().  | 
11307  |  | **   <li> The new object is configured with the rebase buffer obtained from  | 
11308  |  | **        sqlite3changeset_apply_v2() by calling sqlite3rebaser_configure().  | 
11309  |  | **        If the local changeset is to be rebased against multiple remote  | 
11310  |  | **        changesets, then sqlite3rebaser_configure() should be called  | 
11311  |  | **        multiple times, in the same order that the multiple  | 
11312  |  | **        sqlite3changeset_apply_v2() calls were made.  | 
11313  |  | **   <li> Each local changeset is rebased by calling sqlite3rebaser_rebase().  | 
11314  |  | **   <li> The sqlite3_rebaser object is deleted by calling  | 
11315  |  | **        sqlite3rebaser_delete().  | 
11316  |  | ** </ol>  | 
11317  |  | */  | 
11318  |  | typedef struct sqlite3_rebaser sqlite3_rebaser;  | 
11319  |  |  | 
11320  |  | /*  | 
11321  |  | ** CAPI3REF: Create a changeset rebaser object.  | 
11322  |  | ** EXPERIMENTAL  | 
11323  |  | **  | 
11324  |  | ** Allocate a new changeset rebaser object. If successful, set (*ppNew) to  | 
11325  |  | ** point to the new object and return SQLITE_OK. Otherwise, if an error  | 
11326  |  | ** occurs, return an SQLite error code (e.g. SQLITE_NOMEM) and set (*ppNew)  | 
11327  |  | ** to NULL.  | 
11328  |  | */  | 
11329  |  | SQLITE_API int sqlite3rebaser_create(sqlite3_rebaser **ppNew);  | 
11330  |  |  | 
11331  |  | /*  | 
11332  |  | ** CAPI3REF: Configure a changeset rebaser object.  | 
11333  |  | ** EXPERIMENTAL  | 
11334  |  | **  | 
11335  |  | ** Configure the changeset rebaser object to rebase changesets according  | 
11336  |  | ** to the conflict resolutions described by buffer pRebase (size nRebase  | 
11337  |  | ** bytes), which must have been obtained from a previous call to  | 
11338  |  | ** sqlite3changeset_apply_v2().  | 
11339  |  | */  | 
11340  |  | SQLITE_API int sqlite3rebaser_configure(  | 
11341  |  |   sqlite3_rebaser*,  | 
11342  |  |   int nRebase, const void *pRebase  | 
11343  |  | );  | 
11344  |  |  | 
11345  |  | /*  | 
11346  |  | ** CAPI3REF: Rebase a changeset  | 
11347  |  | ** EXPERIMENTAL  | 
11348  |  | **  | 
11349  |  | ** Argument pIn must point to a buffer containing a changeset nIn bytes  | 
11350  |  | ** in size. This function allocates and populates a buffer with a copy  | 
11351  |  | ** of the changeset rebased according to the configuration of the  | 
11352  |  | ** rebaser object passed as the first argument. If successful, (*ppOut)  | 
11353  |  | ** is set to point to the new buffer containing the rebased changeset and  | 
11354  |  | ** (*pnOut) to its size in bytes and SQLITE_OK returned. It is the  | 
11355  |  | ** responsibility of the caller to eventually free the new buffer using  | 
11356  |  | ** sqlite3_free(). Otherwise, if an error occurs, (*ppOut) and (*pnOut)  | 
11357  |  | ** are set to zero and an SQLite error code returned.  | 
11358  |  | */  | 
11359  |  | SQLITE_API int sqlite3rebaser_rebase(  | 
11360  |  |   sqlite3_rebaser*,  | 
11361  |  |   int nIn, const void *pIn,  | 
11362  |  |   int *pnOut, void **ppOut  | 
11363  |  | );  | 
11364  |  |  | 
11365  |  | /*  | 
11366  |  | ** CAPI3REF: Delete a changeset rebaser object.  | 
11367  |  | ** EXPERIMENTAL  | 
11368  |  | **  | 
11369  |  | ** Delete the changeset rebaser object and all associated resources. There  | 
11370  |  | ** should be one call to this function for each successful invocation  | 
11371  |  | ** of sqlite3rebaser_create().  | 
11372  |  | */  | 
11373  |  | SQLITE_API void sqlite3rebaser_delete(sqlite3_rebaser *p);  | 
11374  |  |  | 
11375  |  | /*  | 
11376  |  | ** CAPI3REF: Streaming Versions of API functions.  | 
11377  |  | **  | 
11378  |  | ** The six streaming API xxx_strm() functions serve similar purposes to the  | 
11379  |  | ** corresponding non-streaming API functions:  | 
11380  |  | **  | 
11381  |  | ** <table border=1 style="margin-left:8ex;margin-right:8ex">  | 
11382  |  | **   <tr><th>Streaming function<th>Non-streaming equivalent</th>  | 
11383  |  | **   <tr><td>sqlite3changeset_apply_strm<td>[sqlite3changeset_apply]  | 
11384  |  | **   <tr><td>sqlite3changeset_apply_strm_v2<td>[sqlite3changeset_apply_v2]  | 
11385  |  | **   <tr><td>sqlite3changeset_concat_strm<td>[sqlite3changeset_concat]  | 
11386  |  | **   <tr><td>sqlite3changeset_invert_strm<td>[sqlite3changeset_invert]  | 
11387  |  | **   <tr><td>sqlite3changeset_start_strm<td>[sqlite3changeset_start]  | 
11388  |  | **   <tr><td>sqlite3session_changeset_strm<td>[sqlite3session_changeset]  | 
11389  |  | **   <tr><td>sqlite3session_patchset_strm<td>[sqlite3session_patchset]  | 
11390  |  | ** </table>  | 
11391  |  | **  | 
11392  |  | ** Non-streaming functions that accept changesets (or patchsets) as input  | 
11393  |  | ** require that the entire changeset be stored in a single buffer in memory.  | 
11394  |  | ** Similarly, those that return a changeset or patchset do so by returning  | 
11395  |  | ** a pointer to a single large buffer allocated using sqlite3_malloc().  | 
11396  |  | ** Normally this is convenient. However, if an application running in a  | 
11397  |  | ** low-memory environment is required to handle very large changesets, the  | 
11398  |  | ** large contiguous memory allocations required can become onerous.  | 
11399  |  | **  | 
11400  |  | ** In order to avoid this problem, instead of a single large buffer, input  | 
11401  |  | ** is passed to a streaming API functions by way of a callback function that  | 
11402  |  | ** the sessions module invokes to incrementally request input data as it is  | 
11403  |  | ** required. In all cases, a pair of API function parameters such as  | 
11404  |  | **  | 
11405  |  | **  <pre>  | 
11406  |  | **        int nChangeset,  | 
11407  |  | **        void *pChangeset,  | 
11408  |  | **  </pre>  | 
11409  |  | **  | 
11410  |  | ** Is replaced by:  | 
11411  |  | **  | 
11412  |  | **  <pre>  | 
11413  |  | **        int (*xInput)(void *pIn, void *pData, int *pnData),  | 
11414  |  | **        void *pIn,  | 
11415  |  | **  </pre>  | 
11416  |  | **  | 
11417  |  | ** Each time the xInput callback is invoked by the sessions module, the first  | 
11418  |  | ** argument passed is a copy of the supplied pIn context pointer. The second  | 
11419  |  | ** argument, pData, points to a buffer (*pnData) bytes in size. Assuming no  | 
11420  |  | ** error occurs the xInput method should copy up to (*pnData) bytes of data  | 
11421  |  | ** into the buffer and set (*pnData) to the actual number of bytes copied  | 
11422  |  | ** before returning SQLITE_OK. If the input is completely exhausted, (*pnData)  | 
11423  |  | ** should be set to zero to indicate this. Or, if an error occurs, an SQLite  | 
11424  |  | ** error code should be returned. In all cases, if an xInput callback returns  | 
11425  |  | ** an error, all processing is abandoned and the streaming API function  | 
11426  |  | ** returns a copy of the error code to the caller.  | 
11427  |  | **  | 
11428  |  | ** In the case of sqlite3changeset_start_strm(), the xInput callback may be  | 
11429  |  | ** invoked by the sessions module at any point during the lifetime of the  | 
11430  |  | ** iterator. If such an xInput callback returns an error, the iterator enters  | 
11431  |  | ** an error state, whereby all subsequent calls to iterator functions  | 
11432  |  | ** immediately fail with the same error code as returned by xInput.  | 
11433  |  | **  | 
11434  |  | ** Similarly, streaming API functions that return changesets (or patchsets)  | 
11435  |  | ** return them in chunks by way of a callback function instead of via a  | 
11436  |  | ** pointer to a single large buffer. In this case, a pair of parameters such  | 
11437  |  | ** as:  | 
11438  |  | **  | 
11439  |  | **  <pre>  | 
11440  |  | **        int *pnChangeset,  | 
11441  |  | **        void **ppChangeset,  | 
11442  |  | **  </pre>  | 
11443  |  | **  | 
11444  |  | ** Is replaced by:  | 
11445  |  | **  | 
11446  |  | **  <pre>  | 
11447  |  | **        int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11448  |  | **        void *pOut  | 
11449  |  | **  </pre>  | 
11450  |  | **  | 
11451  |  | ** The xOutput callback is invoked zero or more times to return data to  | 
11452  |  | ** the application. The first parameter passed to each call is a copy of the  | 
11453  |  | ** pOut pointer supplied by the application. The second parameter, pData,  | 
11454  |  | ** points to a buffer nData bytes in size containing the chunk of output  | 
11455  |  | ** data being returned. If the xOutput callback successfully processes the  | 
11456  |  | ** supplied data, it should return SQLITE_OK to indicate success. Otherwise,  | 
11457  |  | ** it should return some other SQLite error code. In this case processing  | 
11458  |  | ** is immediately abandoned and the streaming API function returns a copy  | 
11459  |  | ** of the xOutput error code to the application.  | 
11460  |  | **  | 
11461  |  | ** The sessions module never invokes an xOutput callback with the third  | 
11462  |  | ** parameter set to a value less than or equal to zero. Other than this,  | 
11463  |  | ** no guarantees are made as to the size of the chunks of data returned.  | 
11464  |  | */  | 
11465  |  | SQLITE_API int sqlite3changeset_apply_strm(  | 
11466  |  |   sqlite3 *db,                    /* Apply change to "main" db of this handle */  | 
11467  |  |   int (*xInput)(void *pIn, void *pData, int *pnData), /* Input function */  | 
11468  |  |   void *pIn,                                          /* First arg for xInput */  | 
11469  |  |   int(*xFilter)(  | 
11470  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11471  |  |     const char *zTab              /* Table name */  | 
11472  |  |   ),  | 
11473  |  |   int(*xConflict)(  | 
11474  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11475  |  |     int eConflict,                /* DATA, MISSING, CONFLICT, CONSTRAINT */  | 
11476  |  |     sqlite3_changeset_iter *p     /* Handle describing change and conflict */  | 
11477  |  |   ),  | 
11478  |  |   void *pCtx                      /* First argument passed to xConflict */  | 
11479  |  | );  | 
11480  |  | SQLITE_API int sqlite3changeset_apply_v2_strm(  | 
11481  |  |   sqlite3 *db,                    /* Apply change to "main" db of this handle */  | 
11482  |  |   int (*xInput)(void *pIn, void *pData, int *pnData), /* Input function */  | 
11483  |  |   void *pIn,                                          /* First arg for xInput */  | 
11484  |  |   int(*xFilter)(  | 
11485  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11486  |  |     const char *zTab              /* Table name */  | 
11487  |  |   ),  | 
11488  |  |   int(*xConflict)(  | 
11489  |  |     void *pCtx,                   /* Copy of sixth arg to _apply() */  | 
11490  |  |     int eConflict,                /* DATA, MISSING, CONFLICT, CONSTRAINT */  | 
11491  |  |     sqlite3_changeset_iter *p     /* Handle describing change and conflict */  | 
11492  |  |   ),  | 
11493  |  |   void *pCtx,                     /* First argument passed to xConflict */  | 
11494  |  |   void **ppRebase, int *pnRebase,  | 
11495  |  |   int flags  | 
11496  |  | );  | 
11497  |  | SQLITE_API int sqlite3changeset_concat_strm(  | 
11498  |  |   int (*xInputA)(void *pIn, void *pData, int *pnData),  | 
11499  |  |   void *pInA,  | 
11500  |  |   int (*xInputB)(void *pIn, void *pData, int *pnData),  | 
11501  |  |   void *pInB,  | 
11502  |  |   int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11503  |  |   void *pOut  | 
11504  |  | );  | 
11505  |  | SQLITE_API int sqlite3changeset_invert_strm(  | 
11506  |  |   int (*xInput)(void *pIn, void *pData, int *pnData),  | 
11507  |  |   void *pIn,  | 
11508  |  |   int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11509  |  |   void *pOut  | 
11510  |  | );  | 
11511  |  | SQLITE_API int sqlite3changeset_start_strm(  | 
11512  |  |   sqlite3_changeset_iter **pp,  | 
11513  |  |   int (*xInput)(void *pIn, void *pData, int *pnData),  | 
11514  |  |   void *pIn  | 
11515  |  | );  | 
11516  |  | SQLITE_API int sqlite3changeset_start_v2_strm(  | 
11517  |  |   sqlite3_changeset_iter **pp,  | 
11518  |  |   int (*xInput)(void *pIn, void *pData, int *pnData),  | 
11519  |  |   void *pIn,  | 
11520  |  |   int flags  | 
11521  |  | );  | 
11522  |  | SQLITE_API int sqlite3session_changeset_strm(  | 
11523  |  |   sqlite3_session *pSession,  | 
11524  |  |   int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11525  |  |   void *pOut  | 
11526  |  | );  | 
11527  |  | SQLITE_API int sqlite3session_patchset_strm(  | 
11528  |  |   sqlite3_session *pSession,  | 
11529  |  |   int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11530  |  |   void *pOut  | 
11531  |  | );  | 
11532  |  | SQLITE_API int sqlite3changegroup_add_strm(sqlite3_changegroup*,  | 
11533  |  |     int (*xInput)(void *pIn, void *pData, int *pnData),  | 
11534  |  |     void *pIn  | 
11535  |  | );  | 
11536  |  | SQLITE_API int sqlite3changegroup_output_strm(sqlite3_changegroup*,  | 
11537  |  |     int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11538  |  |     void *pOut  | 
11539  |  | );  | 
11540  |  | SQLITE_API int sqlite3rebaser_rebase_strm(  | 
11541  |  |   sqlite3_rebaser *pRebaser,  | 
11542  |  |   int (*xInput)(void *pIn, void *pData, int *pnData),  | 
11543  |  |   void *pIn,  | 
11544  |  |   int (*xOutput)(void *pOut, const void *pData, int nData),  | 
11545  |  |   void *pOut  | 
11546  |  | );  | 
11547  |  |  | 
11548  |  | /*  | 
11549  |  | ** CAPI3REF: Configure global parameters  | 
11550  |  | **  | 
11551  |  | ** The sqlite3session_config() interface is used to make global configuration  | 
11552  |  | ** changes to the sessions module in order to tune it to the specific needs  | 
11553  |  | ** of the application.  | 
11554  |  | **  | 
11555  |  | ** The sqlite3session_config() interface is not threadsafe. If it is invoked  | 
11556  |  | ** while any other thread is inside any other sessions method then the  | 
11557  |  | ** results are undefined. Furthermore, if it is invoked after any sessions  | 
11558  |  | ** related objects have been created, the results are also undefined.  | 
11559  |  | **  | 
11560  |  | ** The first argument to the sqlite3session_config() function must be one  | 
11561  |  | ** of the SQLITE_SESSION_CONFIG_XXX constants defined below. The  | 
11562  |  | ** interpretation of the (void*) value passed as the second parameter and  | 
11563  |  | ** the effect of calling this function depends on the value of the first  | 
11564  |  | ** parameter.  | 
11565  |  | **  | 
11566  |  | ** <dl>  | 
11567  |  | ** <dt>SQLITE_SESSION_CONFIG_STRMSIZE<dd>  | 
11568  |  | **    By default, the sessions module streaming interfaces attempt to input  | 
11569  |  | **    and output data in approximately 1 KiB chunks. This operand may be used  | 
11570  |  | **    to set and query the value of this configuration setting. The pointer  | 
11571  |  | **    passed as the second argument must point to a value of type (int).  | 
11572  |  | **    If this value is greater than 0, it is used as the new streaming data  | 
11573  |  | **    chunk size for both input and output. Before returning, the (int) value  | 
11574  |  | **    pointed to by pArg is set to the final value of the streaming interface  | 
11575  |  | **    chunk size.  | 
11576  |  | ** </dl>  | 
11577  |  | **  | 
11578  |  | ** This function returns SQLITE_OK if successful, or an SQLite error code  | 
11579  |  | ** otherwise.  | 
11580  |  | */  | 
11581  |  | SQLITE_API int sqlite3session_config(int op, void *pArg);  | 
11582  |  |  | 
11583  |  | /*  | 
11584  |  | ** CAPI3REF: Values for sqlite3session_config().  | 
11585  |  | */  | 
11586  |  | #define SQLITE_SESSION_CONFIG_STRMSIZE 1  | 
11587  |  |  | 
11588  |  | /*  | 
11589  |  | ** Make sure we can call this stuff from C++.  | 
11590  |  | */  | 
11591  |  | #ifdef __cplusplus  | 
11592  |  | }  | 
11593  |  | #endif  | 
11594  |  |  | 
11595  |  | #endif  /* !defined(__SQLITESESSION_H_) && defined(SQLITE_ENABLE_SESSION) */  | 
11596  |  |  | 
11597  |  | /******** End of sqlite3session.h *********/  | 
11598  |  | /******** Begin file fts5.h *********/  | 
11599  |  | /*  | 
11600  |  | ** 2014 May 31  | 
11601  |  | **  | 
11602  |  | ** The author disclaims copyright to this source code.  In place of  | 
11603  |  | ** a legal notice, here is a blessing:  | 
11604  |  | **  | 
11605  |  | **    May you do good and not evil.  | 
11606  |  | **    May you find forgiveness for yourself and forgive others.  | 
11607  |  | **    May you share freely, never taking more than you give.  | 
11608  |  | **  | 
11609  |  | ******************************************************************************  | 
11610  |  | **  | 
11611  |  | ** Interfaces to extend FTS5. Using the interfaces defined in this file,  | 
11612  |  | ** FTS5 may be extended with:  | 
11613  |  | **  | 
11614  |  | **     * custom tokenizers, and  | 
11615  |  | **     * custom auxiliary functions.  | 
11616  |  | */  | 
11617  |  |  | 
11618  |  |  | 
11619  |  | #ifndef _FTS5_H  | 
11620  |  | #define _FTS5_H  | 
11621  |  |  | 
11622  |  |  | 
11623  |  | #ifdef __cplusplus  | 
11624  |  | extern "C" { | 
11625  |  | #endif  | 
11626  |  |  | 
11627  |  | /*************************************************************************  | 
11628  |  | ** CUSTOM AUXILIARY FUNCTIONS  | 
11629  |  | **  | 
11630  |  | ** Virtual table implementations may overload SQL functions by implementing  | 
11631  |  | ** the sqlite3_module.xFindFunction() method.  | 
11632  |  | */  | 
11633  |  |  | 
11634  |  | typedef struct Fts5ExtensionApi Fts5ExtensionApi;  | 
11635  |  | typedef struct Fts5Context Fts5Context;  | 
11636  |  | typedef struct Fts5PhraseIter Fts5PhraseIter;  | 
11637  |  |  | 
11638  |  | typedef void (*fts5_extension_function)(  | 
11639  |  |   const Fts5ExtensionApi *pApi,   /* API offered by current FTS version */  | 
11640  |  |   Fts5Context *pFts,              /* First arg to pass to pApi functions */  | 
11641  |  |   sqlite3_context *pCtx,          /* Context for returning result/error */  | 
11642  |  |   int nVal,                       /* Number of values in apVal[] array */  | 
11643  |  |   sqlite3_value **apVal           /* Array of trailing arguments */  | 
11644  |  | );  | 
11645  |  |  | 
11646  |  | struct Fts5PhraseIter { | 
11647  |  |   const unsigned char *a;  | 
11648  |  |   const unsigned char *b;  | 
11649  |  | };  | 
11650  |  |  | 
11651  |  | /*  | 
11652  |  | ** EXTENSION API FUNCTIONS  | 
11653  |  | **  | 
11654  |  | ** xUserData(pFts):  | 
11655  |  | **   Return a copy of the context pointer the extension function was  | 
11656  |  | **   registered with.  | 
11657  |  | **  | 
11658  |  | ** xColumnTotalSize(pFts, iCol, pnToken):  | 
11659  |  | **   If parameter iCol is less than zero, set output variable *pnToken  | 
11660  |  | **   to the total number of tokens in the FTS5 table. Or, if iCol is  | 
11661  |  | **   non-negative but less than the number of columns in the table, return  | 
11662  |  | **   the total number of tokens in column iCol, considering all rows in  | 
11663  |  | **   the FTS5 table.  | 
11664  |  | **  | 
11665  |  | **   If parameter iCol is greater than or equal to the number of columns  | 
11666  |  | **   in the table, SQLITE_RANGE is returned. Or, if an error occurs (e.g.  | 
11667  |  | **   an OOM condition or IO error), an appropriate SQLite error code is  | 
11668  |  | **   returned.  | 
11669  |  | **  | 
11670  |  | ** xColumnCount(pFts):  | 
11671  |  | **   Return the number of columns in the table.  | 
11672  |  | **  | 
11673  |  | ** xColumnSize(pFts, iCol, pnToken):  | 
11674  |  | **   If parameter iCol is less than zero, set output variable *pnToken  | 
11675  |  | **   to the total number of tokens in the current row. Or, if iCol is  | 
11676  |  | **   non-negative but less than the number of columns in the table, set  | 
11677  |  | **   *pnToken to the number of tokens in column iCol of the current row.  | 
11678  |  | **  | 
11679  |  | **   If parameter iCol is greater than or equal to the number of columns  | 
11680  |  | **   in the table, SQLITE_RANGE is returned. Or, if an error occurs (e.g.  | 
11681  |  | **   an OOM condition or IO error), an appropriate SQLite error code is  | 
11682  |  | **   returned.  | 
11683  |  | **  | 
11684  |  | **   This function may be quite inefficient if used with an FTS5 table  | 
11685  |  | **   created with the "columnsize=0" option.  | 
11686  |  | **  | 
11687  |  | ** xColumnText:  | 
11688  |  | **   This function attempts to retrieve the text of column iCol of the  | 
11689  |  | **   current document. If successful, (*pz) is set to point to a buffer  | 
11690  |  | **   containing the text in utf-8 encoding, (*pn) is set to the size in bytes  | 
11691  |  | **   (not characters) of the buffer and SQLITE_OK is returned. Otherwise,  | 
11692  |  | **   if an error occurs, an SQLite error code is returned and the final values  | 
11693  |  | **   of (*pz) and (*pn) are undefined.  | 
11694  |  | **  | 
11695  |  | ** xPhraseCount:  | 
11696  |  | **   Returns the number of phrases in the current query expression.  | 
11697  |  | **  | 
11698  |  | ** xPhraseSize:  | 
11699  |  | **   Returns the number of tokens in phrase iPhrase of the query. Phrases  | 
11700  |  | **   are numbered starting from zero.  | 
11701  |  | **  | 
11702  |  | ** xInstCount:  | 
11703  |  | **   Set *pnInst to the total number of occurrences of all phrases within  | 
11704  |  | **   the query within the current row. Return SQLITE_OK if successful, or  | 
11705  |  | **   an error code (i.e. SQLITE_NOMEM) if an error occurs.  | 
11706  |  | **  | 
11707  |  | **   This API can be quite slow if used with an FTS5 table created with the  | 
11708  |  | **   "detail=none" or "detail=column" option. If the FTS5 table is created  | 
11709  |  | **   with either "detail=none" or "detail=column" and "content=" option  | 
11710  |  | **   (i.e. if it is a contentless table), then this API always returns 0.  | 
11711  |  | **  | 
11712  |  | ** xInst:  | 
11713  |  | **   Query for the details of phrase match iIdx within the current row.  | 
11714  |  | **   Phrase matches are numbered starting from zero, so the iIdx argument  | 
11715  |  | **   should be greater than or equal to zero and smaller than the value  | 
11716  |  | **   output by xInstCount().  | 
11717  |  | **  | 
11718  |  | **   Usually, output parameter *piPhrase is set to the phrase number, *piCol  | 
11719  |  | **   to the column in which it occurs and *piOff the token offset of the  | 
11720  |  | **   first token of the phrase. Returns SQLITE_OK if successful, or an error  | 
11721  |  | **   code (i.e. SQLITE_NOMEM) if an error occurs.  | 
11722  |  | **  | 
11723  |  | **   This API can be quite slow if used with an FTS5 table created with the  | 
11724  |  | **   "detail=none" or "detail=column" option.  | 
11725  |  | **  | 
11726  |  | ** xRowid:  | 
11727  |  | **   Returns the rowid of the current row.  | 
11728  |  | **  | 
11729  |  | ** xTokenize:  | 
11730  |  | **   Tokenize text using the tokenizer belonging to the FTS5 table.  | 
11731  |  | **  | 
11732  |  | ** xQueryPhrase(pFts5, iPhrase, pUserData, xCallback):  | 
11733  |  | **   This API function is used to query the FTS table for phrase iPhrase  | 
11734  |  | **   of the current query. Specifically, a query equivalent to:  | 
11735  |  | **  | 
11736  |  | **       ... FROM ftstable WHERE ftstable MATCH $p ORDER BY rowid  | 
11737  |  | **  | 
11738  |  | **   with $p set to a phrase equivalent to the phrase iPhrase of the  | 
11739  |  | **   current query is executed. Any column filter that applies to  | 
11740  |  | **   phrase iPhrase of the current query is included in $p. For each  | 
11741  |  | **   row visited, the callback function passed as the fourth argument  | 
11742  |  | **   is invoked. The context and API objects passed to the callback  | 
11743  |  | **   function may be used to access the properties of each matched row.  | 
11744  |  | **   Invoking Api.xUserData() returns a copy of the pointer passed as  | 
11745  |  | **   the third argument to pUserData.  | 
11746  |  | **  | 
11747  |  | **   If the callback function returns any value other than SQLITE_OK, the  | 
11748  |  | **   query is abandoned and the xQueryPhrase function returns immediately.  | 
11749  |  | **   If the returned value is SQLITE_DONE, xQueryPhrase returns SQLITE_OK.  | 
11750  |  | **   Otherwise, the error code is propagated upwards.  | 
11751  |  | **  | 
11752  |  | **   If the query runs to completion without incident, SQLITE_OK is returned.  | 
11753  |  | **   Or, if some error occurs before the query completes or is aborted by  | 
11754  |  | **   the callback, an SQLite error code is returned.  | 
11755  |  | **  | 
11756  |  | **  | 
11757  |  | ** xSetAuxdata(pFts5, pAux, xDelete)  | 
11758  |  | **  | 
11759  |  | **   Save the pointer passed as the second argument as the extension function's  | 
11760  |  | **   "auxiliary data". The pointer may then be retrieved by the current or any  | 
11761  |  | **   future invocation of the same fts5 extension function made as part of  | 
11762  |  | **   the same MATCH query using the xGetAuxdata() API.  | 
11763  |  | **  | 
11764  |  | **   Each extension function is allocated a single auxiliary data slot for  | 
11765  |  | **   each FTS query (MATCH expression). If the extension function is invoked  | 
11766  |  | **   more than once for a single FTS query, then all invocations share a  | 
11767  |  | **   single auxiliary data context.  | 
11768  |  | **  | 
11769  |  | **   If there is already an auxiliary data pointer when this function is  | 
11770  |  | **   invoked, then it is replaced by the new pointer. If an xDelete callback  | 
11771  |  | **   was specified along with the original pointer, it is invoked at this  | 
11772  |  | **   point.  | 
11773  |  | **  | 
11774  |  | **   The xDelete callback, if one is specified, is also invoked on the  | 
11775  |  | **   auxiliary data pointer after the FTS5 query has finished.  | 
11776  |  | **  | 
11777  |  | **   If an error (e.g. an OOM condition) occurs within this function,  | 
11778  |  | **   the auxiliary data is set to NULL and an error code returned. If the  | 
11779  |  | **   xDelete parameter was not NULL, it is invoked on the auxiliary data  | 
11780  |  | **   pointer before returning.  | 
11781  |  | **  | 
11782  |  | **  | 
11783  |  | ** xGetAuxdata(pFts5, bClear)  | 
11784  |  | **  | 
11785  |  | **   Returns the current auxiliary data pointer for the fts5 extension  | 
11786  |  | **   function. See the xSetAuxdata() method for details.  | 
11787  |  | **  | 
11788  |  | **   If the bClear argument is non-zero, then the auxiliary data is cleared  | 
11789  |  | **   (set to NULL) before this function returns. In this case the xDelete,  | 
11790  |  | **   if any, is not invoked.  | 
11791  |  | **  | 
11792  |  | **  | 
11793  |  | ** xRowCount(pFts5, pnRow)  | 
11794  |  | **  | 
11795  |  | **   This function is used to retrieve the total number of rows in the table.  | 
11796  |  | **   In other words, the same value that would be returned by:  | 
11797  |  | **  | 
11798  |  | **        SELECT count(*) FROM ftstable;  | 
11799  |  | **  | 
11800  |  | ** xPhraseFirst()  | 
11801  |  | **   This function is used, along with type Fts5PhraseIter and the xPhraseNext  | 
11802  |  | **   method, to iterate through all instances of a single query phrase within  | 
11803  |  | **   the current row. This is the same information as is accessible via the  | 
11804  |  | **   xInstCount/xInst APIs. While the xInstCount/xInst APIs are more convenient  | 
11805  |  | **   to use, this API may be faster under some circumstances. To iterate  | 
11806  |  | **   through instances of phrase iPhrase, use the following code:  | 
11807  |  | **  | 
11808  |  | **       Fts5PhraseIter iter;  | 
11809  |  | **       int iCol, iOff;  | 
11810  |  | **       for(pApi->xPhraseFirst(pFts, iPhrase, &iter, &iCol, &iOff);  | 
11811  |  | **           iCol>=0;  | 
11812  |  | **           pApi->xPhraseNext(pFts, &iter, &iCol, &iOff)  | 
11813  |  | **       ){ | 
11814  |  | **         // An instance of phrase iPhrase at offset iOff of column iCol  | 
11815  |  | **       }  | 
11816  |  | **  | 
11817  |  | **   The Fts5PhraseIter structure is defined above. Applications should not  | 
11818  |  | **   modify this structure directly - it should only be used as shown above  | 
11819  |  | **   with the xPhraseFirst() and xPhraseNext() API methods (and by  | 
11820  |  | **   xPhraseFirstColumn() and xPhraseNextColumn() as illustrated below).  | 
11821  |  | **  | 
11822  |  | **   This API can be quite slow if used with an FTS5 table created with the  | 
11823  |  | **   "detail=none" or "detail=column" option. If the FTS5 table is created  | 
11824  |  | **   with either "detail=none" or "detail=column" and "content=" option  | 
11825  |  | **   (i.e. if it is a contentless table), then this API always iterates  | 
11826  |  | **   through an empty set (all calls to xPhraseFirst() set iCol to -1).  | 
11827  |  | **  | 
11828  |  | ** xPhraseNext()  | 
11829  |  | **   See xPhraseFirst above.  | 
11830  |  | **  | 
11831  |  | ** xPhraseFirstColumn()  | 
11832  |  | **   This function and xPhraseNextColumn() are similar to the xPhraseFirst()  | 
11833  |  | **   and xPhraseNext() APIs described above. The difference is that instead  | 
11834  |  | **   of iterating through all instances of a phrase in the current row, these  | 
11835  |  | **   APIs are used to iterate through the set of columns in the current row  | 
11836  |  | **   that contain one or more instances of a specified phrase. For example:  | 
11837  |  | **  | 
11838  |  | **       Fts5PhraseIter iter;  | 
11839  |  | **       int iCol;  | 
11840  |  | **       for(pApi->xPhraseFirstColumn(pFts, iPhrase, &iter, &iCol);  | 
11841  |  | **           iCol>=0;  | 
11842  |  | **           pApi->xPhraseNextColumn(pFts, &iter, &iCol)  | 
11843  |  | **       ){ | 
11844  |  | **         // Column iCol contains at least one instance of phrase iPhrase  | 
11845  |  | **       }  | 
11846  |  | **  | 
11847  |  | **   This API can be quite slow if used with an FTS5 table created with the  | 
11848  |  | **   "detail=none" option. If the FTS5 table is created with either  | 
11849  |  | **   "detail=none" "content=" option (i.e. if it is a contentless table),  | 
11850  |  | **   then this API always iterates through an empty set (all calls to  | 
11851  |  | **   xPhraseFirstColumn() set iCol to -1).  | 
11852  |  | **  | 
11853  |  | **   The information accessed using this API and its companion  | 
11854  |  | **   xPhraseFirstColumn() may also be obtained using xPhraseFirst/xPhraseNext  | 
11855  |  | **   (or xInst/xInstCount). The chief advantage of this API is that it is  | 
11856  |  | **   significantly more efficient than those alternatives when used with  | 
11857  |  | **   "detail=column" tables.  | 
11858  |  | **  | 
11859  |  | ** xPhraseNextColumn()  | 
11860  |  | **   See xPhraseFirstColumn above.  | 
11861  |  | */  | 
11862  |  | struct Fts5ExtensionApi { | 
11863  |  |   int iVersion;                   /* Currently always set to 3 */  | 
11864  |  |  | 
11865  |  |   void *(*xUserData)(Fts5Context*);  | 
11866  |  |  | 
11867  |  |   int (*xColumnCount)(Fts5Context*);  | 
11868  |  |   int (*xRowCount)(Fts5Context*, sqlite3_int64 *pnRow);  | 
11869  |  |   int (*xColumnTotalSize)(Fts5Context*, int iCol, sqlite3_int64 *pnToken);  | 
11870  |  |  | 
11871  |  |   int (*xTokenize)(Fts5Context*,  | 
11872  |  |     const char *pText, int nText, /* Text to tokenize */  | 
11873  |  |     void *pCtx,                   /* Context passed to xToken() */  | 
11874  |  |     int (*xToken)(void*, int, const char*, int, int, int)       /* Callback */  | 
11875  |  |   );  | 
11876  |  |  | 
11877  |  |   int (*xPhraseCount)(Fts5Context*);  | 
11878  |  |   int (*xPhraseSize)(Fts5Context*, int iPhrase);  | 
11879  |  |  | 
11880  |  |   int (*xInstCount)(Fts5Context*, int *pnInst);  | 
11881  |  |   int (*xInst)(Fts5Context*, int iIdx, int *piPhrase, int *piCol, int *piOff);  | 
11882  |  |  | 
11883  |  |   sqlite3_int64 (*xRowid)(Fts5Context*);  | 
11884  |  |   int (*xColumnText)(Fts5Context*, int iCol, const char **pz, int *pn);  | 
11885  |  |   int (*xColumnSize)(Fts5Context*, int iCol, int *pnToken);  | 
11886  |  |  | 
11887  |  |   int (*xQueryPhrase)(Fts5Context*, int iPhrase, void *pUserData,  | 
11888  |  |     int(*)(const Fts5ExtensionApi*,Fts5Context*,void*)  | 
11889  |  |   );  | 
11890  |  |   int (*xSetAuxdata)(Fts5Context*, void *pAux, void(*xDelete)(void*));  | 
11891  |  |   void *(*xGetAuxdata)(Fts5Context*, int bClear);  | 
11892  |  |  | 
11893  |  |   int (*xPhraseFirst)(Fts5Context*, int iPhrase, Fts5PhraseIter*, int*, int*);  | 
11894  |  |   void (*xPhraseNext)(Fts5Context*, Fts5PhraseIter*, int *piCol, int *piOff);  | 
11895  |  |  | 
11896  |  |   int (*xPhraseFirstColumn)(Fts5Context*, int iPhrase, Fts5PhraseIter*, int*);  | 
11897  |  |   void (*xPhraseNextColumn)(Fts5Context*, Fts5PhraseIter*, int *piCol);  | 
11898  |  | };  | 
11899  |  |  | 
11900  |  | /*  | 
11901  |  | ** CUSTOM AUXILIARY FUNCTIONS  | 
11902  |  | *************************************************************************/  | 
11903  |  |  | 
11904  |  | /*************************************************************************  | 
11905  |  | ** CUSTOM TOKENIZERS  | 
11906  |  | **  | 
11907  |  | ** Applications may also register custom tokenizer types. A tokenizer  | 
11908  |  | ** is registered by providing fts5 with a populated instance of the  | 
11909  |  | ** following structure. All structure methods must be defined, setting  | 
11910  |  | ** any member of the fts5_tokenizer struct to NULL leads to undefined  | 
11911  |  | ** behaviour. The structure methods are expected to function as follows:  | 
11912  |  | **  | 
11913  |  | ** xCreate:  | 
11914  |  | **   This function is used to allocate and initialize a tokenizer instance.  | 
11915  |  | **   A tokenizer instance is required to actually tokenize text.  | 
11916  |  | **  | 
11917  |  | **   The first argument passed to this function is a copy of the (void*)  | 
11918  |  | **   pointer provided by the application when the fts5_tokenizer object  | 
11919  |  | **   was registered with FTS5 (the third argument to xCreateTokenizer()).  | 
11920  |  | **   The second and third arguments are an array of nul-terminated strings  | 
11921  |  | **   containing the tokenizer arguments, if any, specified following the  | 
11922  |  | **   tokenizer name as part of the CREATE VIRTUAL TABLE statement used  | 
11923  |  | **   to create the FTS5 table.  | 
11924  |  | **  | 
11925  |  | **   The final argument is an output variable. If successful, (*ppOut)  | 
11926  |  | **   should be set to point to the new tokenizer handle and SQLITE_OK  | 
11927  |  | **   returned. If an error occurs, some value other than SQLITE_OK should  | 
11928  |  | **   be returned. In this case, fts5 assumes that the final value of *ppOut  | 
11929  |  | **   is undefined.  | 
11930  |  | **  | 
11931  |  | ** xDelete:  | 
11932  |  | **   This function is invoked to delete a tokenizer handle previously  | 
11933  |  | **   allocated using xCreate(). Fts5 guarantees that this function will  | 
11934  |  | **   be invoked exactly once for each successful call to xCreate().  | 
11935  |  | **  | 
11936  |  | ** xTokenize:  | 
11937  |  | **   This function is expected to tokenize the nText byte string indicated  | 
11938  |  | **   by argument pText. pText may or may not be nul-terminated. The first  | 
11939  |  | **   argument passed to this function is a pointer to an Fts5Tokenizer object  | 
11940  |  | **   returned by an earlier call to xCreate().  | 
11941  |  | **  | 
11942  |  | **   The second argument indicates the reason that FTS5 is requesting  | 
11943  |  | **   tokenization of the supplied text. This is always one of the following  | 
11944  |  | **   four values:  | 
11945  |  | **  | 
11946  |  | **   <ul><li> <b>FTS5_TOKENIZE_DOCUMENT</b> - A document is being inserted into  | 
11947  |  | **            or removed from the FTS table. The tokenizer is being invoked to  | 
11948  |  | **            determine the set of tokens to add to (or delete from) the  | 
11949  |  | **            FTS index.  | 
11950  |  | **  | 
11951  |  | **       <li> <b>FTS5_TOKENIZE_QUERY</b> - A MATCH query is being executed  | 
11952  |  | **            against the FTS index. The tokenizer is being called to tokenize  | 
11953  |  | **            a bareword or quoted string specified as part of the query.  | 
11954  |  | **  | 
11955  |  | **       <li> <b>(FTS5_TOKENIZE_QUERY | FTS5_TOKENIZE_PREFIX)</b> - Same as  | 
11956  |  | **            FTS5_TOKENIZE_QUERY, except that the bareword or quoted string is  | 
11957  |  | **            followed by a "*" character, indicating that the last token  | 
11958  |  | **            returned by the tokenizer will be treated as a token prefix.  | 
11959  |  | **  | 
11960  |  | **       <li> <b>FTS5_TOKENIZE_AUX</b> - The tokenizer is being invoked to  | 
11961  |  | **            satisfy an fts5_api.xTokenize() request made by an auxiliary  | 
11962  |  | **            function. Or an fts5_api.xColumnSize() request made by the same  | 
11963  |  | **            on a columnsize=0 database.  | 
11964  |  | **   </ul>  | 
11965  |  | **  | 
11966  |  | **   For each token in the input string, the supplied callback xToken() must  | 
11967  |  | **   be invoked. The first argument to it should be a copy of the pointer  | 
11968  |  | **   passed as the second argument to xTokenize(). The third and fourth  | 
11969  |  | **   arguments are a pointer to a buffer containing the token text, and the  | 
11970  |  | **   size of the token in bytes. The 4th and 5th arguments are the byte offsets  | 
11971  |  | **   of the first byte of and first byte immediately following the text from  | 
11972  |  | **   which the token is derived within the input.  | 
11973  |  | **  | 
11974  |  | **   The second argument passed to the xToken() callback ("tflags") should | 
11975  |  | **   normally be set to 0. The exception is if the tokenizer supports  | 
11976  |  | **   synonyms. In this case see the discussion below for details.  | 
11977  |  | **  | 
11978  |  | **   FTS5 assumes the xToken() callback is invoked for each token in the  | 
11979  |  | **   order that they occur within the input text.  | 
11980  |  | **  | 
11981  |  | **   If an xToken() callback returns any value other than SQLITE_OK, then  | 
11982  |  | **   the tokenization should be abandoned and the xTokenize() method should  | 
11983  |  | **   immediately return a copy of the xToken() return value. Or, if the  | 
11984  |  | **   input buffer is exhausted, xTokenize() should return SQLITE_OK. Finally,  | 
11985  |  | **   if an error occurs with the xTokenize() implementation itself, it  | 
11986  |  | **   may abandon the tokenization and return any error code other than  | 
11987  |  | **   SQLITE_OK or SQLITE_DONE.  | 
11988  |  | **  | 
11989  |  | ** SYNONYM SUPPORT  | 
11990  |  | **  | 
11991  |  | **   Custom tokenizers may also support synonyms. Consider a case in which a  | 
11992  |  | **   user wishes to query for a phrase such as "first place". Using the  | 
11993  |  | **   built-in tokenizers, the FTS5 query 'first + place' will match instances  | 
11994  |  | **   of "first place" within the document set, but not alternative forms  | 
11995  |  | **   such as "1st place". In some applications, it would be better to match  | 
11996  |  | **   all instances of "first place" or "1st place" regardless of which form  | 
11997  |  | **   the user specified in the MATCH query text.  | 
11998  |  | **  | 
11999  |  | **   There are several ways to approach this in FTS5:  | 
12000  |  | **  | 
12001  |  | **   <ol><li> By mapping all synonyms to a single token. In this case, using  | 
12002  |  | **            the above example, this means that the tokenizer returns the  | 
12003  |  | **            same token for inputs "first" and "1st". Say that token is in  | 
12004  |  | **            fact "first", so that when the user inserts the document "I won  | 
12005  |  | **            1st place" entries are added to the index for tokens "i", "won",  | 
12006  |  | **            "first" and "place". If the user then queries for '1st + place',  | 
12007  |  | **            the tokenizer substitutes "first" for "1st" and the query works  | 
12008  |  | **            as expected.  | 
12009  |  | **  | 
12010  |  | **       <li> By querying the index for all synonyms of each query term  | 
12011  |  | **            separately. In this case, when tokenizing query text, the  | 
12012  |  | **            tokenizer may provide multiple synonyms for a single term  | 
12013  |  | **            within the document. FTS5 then queries the index for each  | 
12014  |  | **            synonym individually. For example, faced with the query:  | 
12015  |  | **  | 
12016  |  | **   <codeblock>  | 
12017  |  | **     ... MATCH 'first place'</codeblock>  | 
12018  |  | **  | 
12019  |  | **            the tokenizer offers both "1st" and "first" as synonyms for the  | 
12020  |  | **            first token in the MATCH query and FTS5 effectively runs a query  | 
12021  |  | **            similar to:  | 
12022  |  | **  | 
12023  |  | **   <codeblock>  | 
12024  |  | **     ... MATCH '(first OR 1st) place'</codeblock>  | 
12025  |  | **  | 
12026  |  | **            except that, for the purposes of auxiliary functions, the query  | 
12027  |  | **            still appears to contain just two phrases - "(first OR 1st)"  | 
12028  |  | **            being treated as a single phrase.  | 
12029  |  | **  | 
12030  |  | **       <li> By adding multiple synonyms for a single term to the FTS index.  | 
12031  |  | **            Using this method, when tokenizing document text, the tokenizer  | 
12032  |  | **            provides multiple synonyms for each token. So that when a  | 
12033  |  | **            document such as "I won first place" is tokenized, entries are  | 
12034  |  | **            added to the FTS index for "i", "won", "first", "1st" and  | 
12035  |  | **            "place".  | 
12036  |  | **  | 
12037  |  | **            This way, even if the tokenizer does not provide synonyms  | 
12038  |  | **            when tokenizing query text (it should not - to do so would be  | 
12039  |  | **            inefficient), it doesn't matter if the user queries for  | 
12040  |  | **            'first + place' or '1st + place', as there are entries in the  | 
12041  |  | **            FTS index corresponding to both forms of the first token.  | 
12042  |  | **   </ol>  | 
12043  |  | **  | 
12044  |  | **   Whether it is parsing document or query text, any call to xToken that  | 
12045  |  | **   specifies a <i>tflags</i> argument with the FTS5_TOKEN_COLOCATED bit  | 
12046  |  | **   is considered to supply a synonym for the previous token. For example,  | 
12047  |  | **   when parsing the document "I won first place", a tokenizer that supports  | 
12048  |  | **   synonyms would call xToken() 5 times, as follows:  | 
12049  |  | **  | 
12050  |  | **   <codeblock>  | 
12051  |  | **       xToken(pCtx, 0, "i",                      1,  0,  1);  | 
12052  |  | **       xToken(pCtx, 0, "won",                    3,  2,  5);  | 
12053  |  | **       xToken(pCtx, 0, "first",                  5,  6, 11);  | 
12054  |  | **       xToken(pCtx, FTS5_TOKEN_COLOCATED, "1st", 3,  6, 11);  | 
12055  |  | **       xToken(pCtx, 0, "place",                  5, 12, 17);  | 
12056  |  | **</codeblock>  | 
12057  |  | **  | 
12058  |  | **   It is an error to specify the FTS5_TOKEN_COLOCATED flag the first time  | 
12059  |  | **   xToken() is called. Multiple synonyms may be specified for a single token  | 
12060  |  | **   by making multiple calls to xToken(FTS5_TOKEN_COLOCATED) in sequence.  | 
12061  |  | **   There is no limit to the number of synonyms that may be provided for a  | 
12062  |  | **   single token.  | 
12063  |  | **  | 
12064  |  | **   In many cases, method (1) above is the best approach. It does not add  | 
12065  |  | **   extra data to the FTS index or require FTS5 to query for multiple terms,  | 
12066  |  | **   so it is efficient in terms of disk space and query speed. However, it  | 
12067  |  | **   does not support prefix queries very well. If, as suggested above, the  | 
12068  |  | **   token "first" is substituted for "1st" by the tokenizer, then the query:  | 
12069  |  | **  | 
12070  |  | **   <codeblock>  | 
12071  |  | **     ... MATCH '1s*'</codeblock>  | 
12072  |  | **  | 
12073  |  | **   will not match documents that contain the token "1st" (as the tokenizer  | 
12074  |  | **   will probably not map "1s" to any prefix of "first").  | 
12075  |  | **  | 
12076  |  | **   For full prefix support, method (3) may be preferred. In this case,  | 
12077  |  | **   because the index contains entries for both "first" and "1st", prefix  | 
12078  |  | **   queries such as 'fi*' or '1s*' will match correctly. However, because  | 
12079  |  | **   extra entries are added to the FTS index, this method uses more space  | 
12080  |  | **   within the database.  | 
12081  |  | **  | 
12082  |  | **   Method (2) offers a midpoint between (1) and (3). Using this method,  | 
12083  |  | **   a query such as '1s*' will match documents that contain the literal  | 
12084  |  | **   token "1st", but not "first" (assuming the tokenizer is not able to  | 
12085  |  | **   provide synonyms for prefixes). However, a non-prefix query like '1st'  | 
12086  |  | **   will match against "1st" and "first". This method does not require  | 
12087  |  | **   extra disk space, as no extra entries are added to the FTS index.  | 
12088  |  | **   On the other hand, it may require more CPU cycles to run MATCH queries,  | 
12089  |  | **   as separate queries of the FTS index are required for each synonym.  | 
12090  |  | **  | 
12091  |  | **   When using methods (2) or (3), it is important that the tokenizer only  | 
12092  |  | **   provide synonyms when tokenizing document text (method (2)) or query  | 
12093  |  | **   text (method (3)), not both. Doing so will not cause any errors, but is  | 
12094  |  | **   inefficient.  | 
12095  |  | */  | 
12096  |  | typedef struct Fts5Tokenizer Fts5Tokenizer;  | 
12097  |  | typedef struct fts5_tokenizer fts5_tokenizer;  | 
12098  |  | struct fts5_tokenizer { | 
12099  |  |   int (*xCreate)(void*, const char **azArg, int nArg, Fts5Tokenizer **ppOut);  | 
12100  |  |   void (*xDelete)(Fts5Tokenizer*);  | 
12101  |  |   int (*xTokenize)(Fts5Tokenizer*,  | 
12102  |  |       void *pCtx,  | 
12103  |  |       int flags,            /* Mask of FTS5_TOKENIZE_* flags */  | 
12104  |  |       const char *pText, int nText,  | 
12105  |  |       int (*xToken)(  | 
12106  |  |         void *pCtx,         /* Copy of 2nd argument to xTokenize() */  | 
12107  |  |         int tflags,         /* Mask of FTS5_TOKEN_* flags */  | 
12108  |  |         const char *pToken, /* Pointer to buffer containing token */  | 
12109  |  |         int nToken,         /* Size of token in bytes */  | 
12110  |  |         int iStart,         /* Byte offset of token within input text */  | 
12111  |  |         int iEnd            /* Byte offset of end of token within input text */  | 
12112  |  |       )  | 
12113  |  |   );  | 
12114  |  | };  | 
12115  |  |  | 
12116  |  | /* Flags that may be passed as the third argument to xTokenize() */  | 
12117  |  | #define FTS5_TOKENIZE_QUERY     0x0001  | 
12118  |  | #define FTS5_TOKENIZE_PREFIX    0x0002  | 
12119  |  | #define FTS5_TOKENIZE_DOCUMENT  0x0004  | 
12120  |  | #define FTS5_TOKENIZE_AUX       0x0008  | 
12121  |  |  | 
12122  |  | /* Flags that may be passed by the tokenizer implementation back to FTS5  | 
12123  |  | ** as the third argument to the supplied xToken callback. */  | 
12124  |  | #define FTS5_TOKEN_COLOCATED    0x0001      /* Same position as prev. token */  | 
12125  |  |  | 
12126  |  | /*  | 
12127  |  | ** END OF CUSTOM TOKENIZERS  | 
12128  |  | *************************************************************************/  | 
12129  |  |  | 
12130  |  | /*************************************************************************  | 
12131  |  | ** FTS5 EXTENSION REGISTRATION API  | 
12132  |  | */  | 
12133  |  | typedef struct fts5_api fts5_api;  | 
12134  |  | struct fts5_api { | 
12135  |  |   int iVersion;                   /* Currently always set to 2 */  | 
12136  |  |  | 
12137  |  |   /* Create a new tokenizer */  | 
12138  |  |   int (*xCreateTokenizer)(  | 
12139  |  |     fts5_api *pApi,  | 
12140  |  |     const char *zName,  | 
12141  |  |     void *pContext,  | 
12142  |  |     fts5_tokenizer *pTokenizer,  | 
12143  |  |     void (*xDestroy)(void*)  | 
12144  |  |   );  | 
12145  |  |  | 
12146  |  |   /* Find an existing tokenizer */  | 
12147  |  |   int (*xFindTokenizer)(  | 
12148  |  |     fts5_api *pApi,  | 
12149  |  |     const char *zName,  | 
12150  |  |     void **ppContext,  | 
12151  |  |     fts5_tokenizer *pTokenizer  | 
12152  |  |   );  | 
12153  |  |  | 
12154  |  |   /* Create a new auxiliary function */  | 
12155  |  |   int (*xCreateFunction)(  | 
12156  |  |     fts5_api *pApi,  | 
12157  |  |     const char *zName,  | 
12158  |  |     void *pContext,  | 
12159  |  |     fts5_extension_function xFunction,  | 
12160  |  |     void (*xDestroy)(void*)  | 
12161  |  |   );  | 
12162  |  | };  | 
12163  |  |  | 
12164  |  | /*  | 
12165  |  | ** END OF REGISTRATION API  | 
12166  |  | *************************************************************************/  | 
12167  |  |  | 
12168  |  | #ifdef __cplusplus  | 
12169  |  | }  /* end of the 'extern "C"' block */  | 
12170  |  | #endif  | 
12171  |  |  | 
12172  |  | #endif /* _FTS5_H */  | 
12173  |  |  | 
12174  |  | /******** End of fts5.h *********/  |