amalgalite 0.11.0 → 0.12.0
Sign up to get free protection for your applications and to get access to all the features.
- data/HISTORY +17 -3
- data/ext/amalgalite/amalgalite3.c +10 -0
- data/ext/amalgalite/amalgalite3_database.c +4 -3
- data/ext/amalgalite/amalgalite3_requires_bootstrap.c +1 -1
- data/ext/amalgalite/amalgalite3_statement.c +15 -5
- data/ext/amalgalite/sqlite3.c +7247 -3690
- data/ext/amalgalite/sqlite3.h +226 -108
- data/gemspec.rb +2 -0
- data/lib/amalgalite/database.rb +4 -0
- data/lib/amalgalite/schema.rb +11 -4
- data/lib/amalgalite/statement.rb +1 -1
- data/lib/amalgalite/version.rb +1 -1
- data/spec/database_spec.rb +27 -5
- data/spec/function_spec.rb +6 -3
- data/spec/schema_spec.rb +32 -15
- data/spec/sqlite3/status_spec.rb +5 -1
- data/spec/sqlite3/version_spec.rb +5 -5
- data/tasks/extension.rake +53 -0
- metadata +121 -82
- data/examples/gems.db +0 -0
data/ext/amalgalite/sqlite3.h
CHANGED
@@ -18,8 +18,8 @@
|
|
18
18
|
** Some of the definitions that are in this file are marked as
|
19
19
|
** "experimental". Experimental interfaces are normally new
|
20
20
|
** features recently added to SQLite. We do not anticipate changes
|
21
|
-
** to experimental interfaces but reserve to make minor changes
|
22
|
-
** experience from use "in the wild" suggest such changes are prudent.
|
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
23
|
**
|
24
24
|
** The official C-language API documentation for SQLite is derived
|
25
25
|
** from comments in this file. This file is the authoritative source
|
@@ -29,8 +29,6 @@
|
|
29
29
|
** The makefile makes some minor changes to this file (such as inserting
|
30
30
|
** the version number) and changes its name to "sqlite3.h" as
|
31
31
|
** part of the build process.
|
32
|
-
**
|
33
|
-
** @(#) $Id: sqlite.h.in,v 1.462 2009/08/06 17:40:46 drh Exp $
|
34
32
|
*/
|
35
33
|
#ifndef _SQLITE3_H_
|
36
34
|
#define _SQLITE3_H_
|
@@ -59,7 +57,7 @@ extern "C" {
|
|
59
57
|
/*
|
60
58
|
** These no-op macros are used in front of interfaces to mark those
|
61
59
|
** interfaces as either deprecated or experimental. New applications
|
62
|
-
** should not use deprecated
|
60
|
+
** should not use deprecated interfaces - they are support for backwards
|
63
61
|
** compatibility only. Application writers should be aware that
|
64
62
|
** experimental interfaces are subject to change in point releases.
|
65
63
|
**
|
@@ -89,51 +87,81 @@ extern "C" {
|
|
89
87
|
** the sqlite3.h file specify the version of SQLite with which
|
90
88
|
** that header file is associated.
|
91
89
|
**
|
92
|
-
** The "version" of SQLite is a string of the form "X.Y.Z".
|
93
|
-
** The
|
94
|
-
** The
|
95
|
-
** The X value only changes when backwards compatibility is
|
90
|
+
** The "version" of SQLite is a string of the form "W.X.Y" or "W.X.Y.Z".
|
91
|
+
** The W value is major version number and is always 3 in SQLite3.
|
92
|
+
** The W value only changes when backwards compatibility is
|
96
93
|
** broken and we intend to never break backwards compatibility.
|
97
|
-
** The
|
94
|
+
** The X value is the minor version number and only changes when
|
98
95
|
** there are major feature enhancements that are forwards compatible
|
99
96
|
** but not backwards compatible.
|
100
|
-
** The
|
101
|
-
** each release but resets back to 0 whenever
|
97
|
+
** The Y value is the release number and is incremented with
|
98
|
+
** each release but resets back to 0 whenever X is incremented.
|
99
|
+
** The Z value only appears on branch releases.
|
100
|
+
**
|
101
|
+
** The SQLITE_VERSION_NUMBER is an integer that is computed as
|
102
|
+
** follows:
|
103
|
+
**
|
104
|
+
** <blockquote><pre>
|
105
|
+
** SQLITE_VERSION_NUMBER = W*1000000 + X*1000 + Y
|
106
|
+
** </pre></blockquote>
|
107
|
+
**
|
108
|
+
** Since version 3.6.18, SQLite source code has been stored in the
|
109
|
+
** <a href="http://www.fossil-scm.org/">fossil configuration management
|
110
|
+
** system</a>. The SQLITE_SOURCE_ID
|
111
|
+
** macro is a string which identifies a particular check-in of SQLite
|
112
|
+
** within its configuration management system. The string contains the
|
113
|
+
** date and time of the check-in (UTC) and an SHA1 hash of the entire
|
114
|
+
** source tree.
|
102
115
|
**
|
103
|
-
** See also: [sqlite3_libversion()]
|
116
|
+
** See also: [sqlite3_libversion()],
|
117
|
+
** [sqlite3_libversion_number()], [sqlite3_sourceid()],
|
118
|
+
** [sqlite_version()] and [sqlite_source_id()].
|
104
119
|
**
|
105
120
|
** Requirements: [H10011] [H10014]
|
106
121
|
*/
|
107
|
-
#define SQLITE_VERSION
|
108
|
-
#define SQLITE_VERSION_NUMBER
|
122
|
+
#define SQLITE_VERSION "3.6.19"
|
123
|
+
#define SQLITE_VERSION_NUMBER 3006019
|
124
|
+
#define SQLITE_SOURCE_ID "2009-10-14 11:33:55 c1d499afc50d54b376945b4efb65c56c787a073d"
|
109
125
|
|
110
126
|
/*
|
111
127
|
** CAPI3REF: Run-Time Library Version Numbers {H10020} <S60100>
|
112
128
|
** KEYWORDS: sqlite3_version
|
113
129
|
**
|
114
|
-
** These
|
115
|
-
** and [
|
116
|
-
** with the library instead of the header file. Cautious
|
117
|
-
** include
|
118
|
-
**
|
119
|
-
**
|
130
|
+
** These interfaces provide the same information as the [SQLITE_VERSION],
|
131
|
+
** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] #defines in the header,
|
132
|
+
** but are associated with the library instead of the header file. Cautious
|
133
|
+
** programmers might include assert() statements in their application to
|
134
|
+
** verify that values returned by these interfaces match the macros in
|
135
|
+
** the header, and thus insure that the application is
|
136
|
+
** compiled with matching library and header files.
|
137
|
+
**
|
138
|
+
** <blockquote><pre>
|
139
|
+
** assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );
|
140
|
+
** assert( strcmp(sqlite3_sourceid(),SQLITE_SOURCE_ID)==0 );
|
141
|
+
** assert( strcmp(sqlite3_libversion,SQLITE_VERSION)==0 );
|
142
|
+
** </pre></blockquote>
|
120
143
|
**
|
121
144
|
** The sqlite3_libversion() function returns the same information as is
|
122
145
|
** in the sqlite3_version[] string constant. The function is provided
|
123
146
|
** for use in DLLs since DLL users usually do not have direct access to string
|
124
|
-
** constants within the DLL.
|
147
|
+
** constants within the DLL. Similarly, the sqlite3_sourceid() function
|
148
|
+
** returns the same information as is in the [SQLITE_SOURCE_ID] #define of
|
149
|
+
** the header file.
|
150
|
+
**
|
151
|
+
** See also: [sqlite_version()] and [sqlite_source_id()].
|
125
152
|
**
|
126
153
|
** Requirements: [H10021] [H10022] [H10023]
|
127
154
|
*/
|
128
155
|
SQLITE_API SQLITE_EXTERN const char sqlite3_version[];
|
129
156
|
SQLITE_API const char *sqlite3_libversion(void);
|
157
|
+
SQLITE_API const char *sqlite3_sourceid(void);
|
130
158
|
SQLITE_API int sqlite3_libversion_number(void);
|
131
159
|
|
132
160
|
/*
|
133
161
|
** CAPI3REF: Test To See If The Library Is Threadsafe {H10100} <S60100>
|
134
162
|
**
|
135
163
|
** SQLite can be compiled with or without mutexes. When
|
136
|
-
** the [SQLITE_THREADSAFE] C preprocessor macro 1 or 2, mutexes
|
164
|
+
** the [SQLITE_THREADSAFE] C preprocessor macro is 1 or 2, mutexes
|
137
165
|
** are enabled and SQLite is threadsafe. When the
|
138
166
|
** [SQLITE_THREADSAFE] macro is 0,
|
139
167
|
** the mutexes are omitted. Without the mutexes, it is not safe
|
@@ -144,7 +172,7 @@ SQLITE_API int sqlite3_libversion_number(void);
|
|
144
172
|
** the mutexes. But for maximum safety, mutexes should be enabled.
|
145
173
|
** The default behavior is for mutexes to be enabled.
|
146
174
|
**
|
147
|
-
** This interface can be used by
|
175
|
+
** This interface can be used by an application to make sure that the
|
148
176
|
** version of SQLite that it is linking against was compiled with
|
149
177
|
** the desired setting of the [SQLITE_THREADSAFE] macro.
|
150
178
|
**
|
@@ -411,6 +439,8 @@ SQLITE_API int sqlite3_exec(
|
|
411
439
|
#define SQLITE_OPEN_MASTER_JOURNAL 0x00004000 /* VFS only */
|
412
440
|
#define SQLITE_OPEN_NOMUTEX 0x00008000 /* Ok for sqlite3_open_v2() */
|
413
441
|
#define SQLITE_OPEN_FULLMUTEX 0x00010000 /* Ok for sqlite3_open_v2() */
|
442
|
+
#define SQLITE_OPEN_SHAREDCACHE 0x00020000 /* Ok for sqlite3_open_v2() */
|
443
|
+
#define SQLITE_OPEN_PRIVATECACHE 0x00040000 /* Ok for sqlite3_open_v2() */
|
414
444
|
|
415
445
|
/*
|
416
446
|
** CAPI3REF: Device Characteristics {H10240} <H11120>
|
@@ -478,8 +508,9 @@ SQLITE_API int sqlite3_exec(
|
|
478
508
|
/*
|
479
509
|
** CAPI3REF: OS Interface Open File Handle {H11110} <S20110>
|
480
510
|
**
|
481
|
-
** An [sqlite3_file] object represents an open file in the
|
482
|
-
** interface layer. Individual OS interface
|
511
|
+
** An [sqlite3_file] object represents an open file in the
|
512
|
+
** [sqlite3_vfs | OS interface layer]. Individual OS interface
|
513
|
+
** implementations will
|
483
514
|
** want to subclass this object by appending additional fields
|
484
515
|
** for their own use. The pMethods entry is a pointer to an
|
485
516
|
** [sqlite3_io_methods] object that defines methods for performing
|
@@ -855,8 +886,9 @@ struct sqlite3_vfs {
|
|
855
886
|
** interface is called automatically by sqlite3_initialize() and
|
856
887
|
** sqlite3_os_end() is called by sqlite3_shutdown(). Appropriate
|
857
888
|
** implementations for sqlite3_os_init() and sqlite3_os_end()
|
858
|
-
** are built into SQLite when it is compiled for
|
859
|
-
** When built for other platforms
|
889
|
+
** are built into SQLite when it is compiled for Unix, Windows, or OS/2.
|
890
|
+
** When [custom builds | built for other platforms]
|
891
|
+
** (using the [SQLITE_OS_OTHER=1] compile-time
|
860
892
|
** option) the application must supply a suitable implementation for
|
861
893
|
** sqlite3_os_init() and sqlite3_os_end(). An application-supplied
|
862
894
|
** implementation of sqlite3_os_init() or sqlite3_os_end()
|
@@ -937,13 +969,15 @@ SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_db_config(sqlite3*, int op, ...);
|
|
937
969
|
** This object is used in only one place in the SQLite interface.
|
938
970
|
** A pointer to an instance of this object is the argument to
|
939
971
|
** [sqlite3_config()] when the configuration option is
|
940
|
-
** [SQLITE_CONFIG_MALLOC].
|
941
|
-
**
|
942
|
-
**
|
943
|
-
**
|
944
|
-
**
|
945
|
-
**
|
946
|
-
**
|
972
|
+
** [SQLITE_CONFIG_MALLOC] or [SQLITE_CONFIG_GETMALLOC].
|
973
|
+
** By creating an instance of this object
|
974
|
+
** and passing it to [sqlite3_config]([SQLITE_CONFIG_MALLOC])
|
975
|
+
** during configuration, an application can specify an alternative
|
976
|
+
** memory allocation subsystem for SQLite to use for all of its
|
977
|
+
** dynamic memory needs.
|
978
|
+
**
|
979
|
+
** Note that SQLite comes with several [built-in memory allocators]
|
980
|
+
** that are perfectly adequate for the overwhelming majority of applications
|
947
981
|
** and that this object is only useful to a tiny minority of applications
|
948
982
|
** with specialized memory allocation requirements. This object is
|
949
983
|
** also used during testing of SQLite in order to specify an alternative
|
@@ -951,8 +985,16 @@ SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_db_config(sqlite3*, int op, ...);
|
|
951
985
|
** order to verify that SQLite recovers gracefully from such
|
952
986
|
** conditions.
|
953
987
|
**
|
954
|
-
** The xMalloc
|
955
|
-
** malloc()
|
988
|
+
** The xMalloc and xFree methods must work like the
|
989
|
+
** malloc() and free() functions from the standard C library.
|
990
|
+
** The xRealloc method must work like realloc() from the standard C library
|
991
|
+
** with the exception that if the second argument to xRealloc is zero,
|
992
|
+
** xRealloc must be a no-op - it must not perform any allocation or
|
993
|
+
** deallocation. SQLite guaranteeds that the second argument to
|
994
|
+
** xRealloc is always a value returned by a prior call to xRoundup.
|
995
|
+
** And so in cases where xRoundup always returns a positive number,
|
996
|
+
** xRealloc can perform exactly as the standard library realloc() and
|
997
|
+
** still be in compliance with this specification.
|
956
998
|
**
|
957
999
|
** xSize should return the allocated size of a memory allocation
|
958
1000
|
** previously obtained from xMalloc or xRealloc. The allocated size
|
@@ -962,6 +1004,9 @@ SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_db_config(sqlite3*, int op, ...);
|
|
962
1004
|
** a memory allocation given a particular requested size. Most memory
|
963
1005
|
** allocators round up memory allocations at least to the next multiple
|
964
1006
|
** of 8. Some allocators round up to a larger multiple or to a power of 2.
|
1007
|
+
** Every memory allocation request coming in through [sqlite3_malloc()]
|
1008
|
+
** or [sqlite3_realloc()] first calls xRoundup. If xRoundup returns 0,
|
1009
|
+
** that causes the corresponding memory allocation to fail.
|
965
1010
|
**
|
966
1011
|
** The xInit method initializes the memory allocator. (For example,
|
967
1012
|
** it might allocate any require mutexes or initialize internal data
|
@@ -969,6 +1014,20 @@ SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_db_config(sqlite3*, int op, ...);
|
|
969
1014
|
** [sqlite3_shutdown()] and should deallocate any resources acquired
|
970
1015
|
** by xInit. The pAppData pointer is used as the only parameter to
|
971
1016
|
** xInit and xShutdown.
|
1017
|
+
**
|
1018
|
+
** SQLite holds the [SQLITE_MUTEX_STATIC_MASTER] mutex when it invokes
|
1019
|
+
** the xInit method, so the xInit method need not be threadsafe. The
|
1020
|
+
** xShutdown method is only called from [sqlite3_shutdown()] so it does
|
1021
|
+
** not need to be threadsafe either. For all other methods, SQLite
|
1022
|
+
** holds the [SQLITE_MUTEX_STATIC_MEM] mutex as long as the
|
1023
|
+
** [SQLITE_CONFIG_MEMSTATUS] configuration option is turned on (which
|
1024
|
+
** it is by default) and so the methods are automatically serialized.
|
1025
|
+
** However, if [SQLITE_CONFIG_MEMSTATUS] is disabled, then the other
|
1026
|
+
** methods must be threadsafe or else make their own arrangements for
|
1027
|
+
** serialization.
|
1028
|
+
**
|
1029
|
+
** SQLite will never invoke xInit() more than once without an intervening
|
1030
|
+
** call to xShutdown().
|
972
1031
|
*/
|
973
1032
|
typedef struct sqlite3_mem_methods sqlite3_mem_methods;
|
974
1033
|
struct sqlite3_mem_methods {
|
@@ -1122,9 +1181,12 @@ struct sqlite3_mem_methods {
|
|
1122
1181
|
**
|
1123
1182
|
** <dt>SQLITE_CONFIG_LOOKASIDE</dt>
|
1124
1183
|
** <dd>This option takes two arguments that determine the default
|
1125
|
-
** memory
|
1184
|
+
** memory allocation lookaside optimization. The first argument is the
|
1126
1185
|
** size of each lookaside buffer slot and the second is the number of
|
1127
|
-
** slots allocated to each database connection
|
1186
|
+
** slots allocated to each database connection. This option sets the
|
1187
|
+
** <i>default</i> lookaside size. The [SQLITE_DBCONFIG_LOOKASIDE]
|
1188
|
+
** verb to [sqlite3_db_config()] can be used to change the lookaside
|
1189
|
+
** configuration on individual connections.</dd>
|
1128
1190
|
**
|
1129
1191
|
** <dt>SQLITE_CONFIG_PCACHE</dt>
|
1130
1192
|
** <dd>This option takes a single argument which is a pointer to
|
@@ -1174,12 +1236,15 @@ struct sqlite3_mem_methods {
|
|
1174
1236
|
** <dd>This option takes three additional arguments that determine the
|
1175
1237
|
** [lookaside memory allocator] configuration for the [database connection].
|
1176
1238
|
** The first argument (the third parameter to [sqlite3_db_config()] is a
|
1177
|
-
** pointer to an
|
1239
|
+
** pointer to an memory buffer to use for lookaside memory.
|
1178
1240
|
** The first argument may be NULL in which case SQLite will allocate the
|
1179
1241
|
** lookaside buffer itself using [sqlite3_malloc()]. The second argument is the
|
1180
1242
|
** size of each lookaside buffer slot and the third argument is the number of
|
1181
1243
|
** slots. The size of the buffer in the first argument must be greater than
|
1182
|
-
** or equal to the product of the second and third arguments
|
1244
|
+
** or equal to the product of the second and third arguments. The buffer
|
1245
|
+
** must be aligned to an 8-byte boundary. If the second argument is not
|
1246
|
+
** a multiple of 8, it is internally rounded down to the next smaller
|
1247
|
+
** multiple of 8. See also: [SQLITE_CONFIG_LOOKASIDE]</dd>
|
1183
1248
|
**
|
1184
1249
|
** </dl>
|
1185
1250
|
*/
|
@@ -1251,8 +1316,9 @@ SQLITE_API sqlite3_int64 sqlite3_last_insert_rowid(sqlite3*);
|
|
1251
1316
|
** on the [database connection] specified by the first parameter.
|
1252
1317
|
** Only changes that are directly specified by the [INSERT], [UPDATE],
|
1253
1318
|
** or [DELETE] statement are counted. Auxiliary changes caused by
|
1254
|
-
** triggers are not counted. Use the
|
1255
|
-
** to find the total number of changes
|
1319
|
+
** triggers or [foreign key actions] are not counted. Use the
|
1320
|
+
** [sqlite3_total_changes()] function to find the total number of changes
|
1321
|
+
** including changes caused by triggers and foreign key actions.
|
1256
1322
|
**
|
1257
1323
|
** Changes to a view that are simulated by an [INSTEAD OF trigger]
|
1258
1324
|
** are not counted. Only real table changes are counted.
|
@@ -1304,8 +1370,8 @@ SQLITE_API int sqlite3_changes(sqlite3*);
|
|
1304
1370
|
**
|
1305
1371
|
** This function returns the number of row changes caused by [INSERT],
|
1306
1372
|
** [UPDATE] or [DELETE] statements since the [database connection] was opened.
|
1307
|
-
** The count includes all changes from all
|
1308
|
-
** [
|
1373
|
+
** The count includes all changes from all [CREATE TRIGGER | trigger]
|
1374
|
+
** contexts and changes made by [foreign key actions]. However,
|
1309
1375
|
** the count does not include changes used to implement [REPLACE] constraints,
|
1310
1376
|
** do rollbacks or ABORT processing, or [DROP TABLE] processing. The
|
1311
1377
|
** count does not include rows of views that fire an [INSTEAD OF trigger],
|
@@ -1583,7 +1649,7 @@ SQLITE_API void sqlite3_free_table(char **result);
|
|
1583
1649
|
/*
|
1584
1650
|
** CAPI3REF: Formatted String Printing Functions {H17400} <S70000><S20000>
|
1585
1651
|
**
|
1586
|
-
** These routines are
|
1652
|
+
** These routines are work-alikes of the "printf()" family of functions
|
1587
1653
|
** from the standard C library.
|
1588
1654
|
**
|
1589
1655
|
** The sqlite3_mprintf() and sqlite3_vmprintf() routines write their
|
@@ -1870,7 +1936,7 @@ SQLITE_API void sqlite3_randomness(int N, void *P);
|
|
1870
1936
|
** database connections for the meaning of "modify" in this paragraph.
|
1871
1937
|
**
|
1872
1938
|
** When [sqlite3_prepare_v2()] is used to prepare a statement, the
|
1873
|
-
** statement might be
|
1939
|
+
** statement might be re-prepared during [sqlite3_step()] due to a
|
1874
1940
|
** schema change. Hence, the application should ensure that the
|
1875
1941
|
** correct authorizer callback remains in place during the [sqlite3_step()].
|
1876
1942
|
**
|
@@ -2037,7 +2103,8 @@ SQLITE_API void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);
|
|
2037
2103
|
** except that it accepts two additional parameters for additional control
|
2038
2104
|
** over the new database connection. The flags parameter can take one of
|
2039
2105
|
** the following three values, optionally combined with the
|
2040
|
-
** [SQLITE_OPEN_NOMUTEX]
|
2106
|
+
** [SQLITE_OPEN_NOMUTEX], [SQLITE_OPEN_FULLMUTEX], [SQLITE_OPEN_SHAREDCACHE],
|
2107
|
+
** and/or [SQLITE_OPEN_PRIVATECACHE] flags:
|
2041
2108
|
**
|
2042
2109
|
** <dl>
|
2043
2110
|
** <dt>[SQLITE_OPEN_READONLY]</dt>
|
@@ -2057,7 +2124,8 @@ SQLITE_API void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);
|
|
2057
2124
|
**
|
2058
2125
|
** If the 3rd parameter to sqlite3_open_v2() is not one of the
|
2059
2126
|
** combinations shown above or one of the combinations shown above combined
|
2060
|
-
** with the [SQLITE_OPEN_NOMUTEX]
|
2127
|
+
** with the [SQLITE_OPEN_NOMUTEX], [SQLITE_OPEN_FULLMUTEX],
|
2128
|
+
** [SQLITE_OPEN_SHAREDCACHE] and/or [SQLITE_OPEN_SHAREDCACHE] flags,
|
2061
2129
|
** then the behavior is undefined.
|
2062
2130
|
**
|
2063
2131
|
** If the [SQLITE_OPEN_NOMUTEX] flag is set, then the database connection
|
@@ -2066,6 +2134,11 @@ SQLITE_API void sqlite3_progress_handler(sqlite3*, int, int(*)(void*), void*);
|
|
2066
2134
|
** [SQLITE_OPEN_FULLMUTEX] flag is set then the database connection opens
|
2067
2135
|
** in the serialized [threading mode] unless single-thread was
|
2068
2136
|
** previously selected at compile-time or start-time.
|
2137
|
+
** The [SQLITE_OPEN_SHAREDCACHE] flag causes the database connection to be
|
2138
|
+
** eligible to use [shared cache mode], regardless of whether or not shared
|
2139
|
+
** cache is enabled using [sqlite3_enable_shared_cache()]. The
|
2140
|
+
** [SQLITE_OPEN_PRIVATECACHE] flag causes the database connection to not
|
2141
|
+
** participate in [shared cache mode] even if it is enabled.
|
2069
2142
|
**
|
2070
2143
|
** If the filename is ":memory:", then a private, temporary in-memory database
|
2071
2144
|
** is created for the connection. This in-memory database will vanish when
|
@@ -2259,6 +2332,9 @@ SQLITE_API int sqlite3_limit(sqlite3*, int id, int newVal);
|
|
2259
2332
|
** <dt>SQLITE_LIMIT_VARIABLE_NUMBER</dt>
|
2260
2333
|
** <dd>The maximum number of variables in an SQL statement that can
|
2261
2334
|
** be bound.</dd>
|
2335
|
+
**
|
2336
|
+
** <dt>SQLITE_LIMIT_TRIGGER_DEPTH</dt>
|
2337
|
+
** <dd>The maximum depth of recursion for triggers.</dd>
|
2262
2338
|
** </dl>
|
2263
2339
|
*/
|
2264
2340
|
#define SQLITE_LIMIT_LENGTH 0
|
@@ -2271,6 +2347,7 @@ SQLITE_API int sqlite3_limit(sqlite3*, int id, int newVal);
|
|
2271
2347
|
#define SQLITE_LIMIT_ATTACHED 7
|
2272
2348
|
#define SQLITE_LIMIT_LIKE_PATTERN_LENGTH 8
|
2273
2349
|
#define SQLITE_LIMIT_VARIABLE_NUMBER 9
|
2350
|
+
#define SQLITE_LIMIT_TRIGGER_DEPTH 10
|
2274
2351
|
|
2275
2352
|
/*
|
2276
2353
|
** CAPI3REF: Compiling An SQL Statement {H13010} <S10000>
|
@@ -2447,7 +2524,8 @@ typedef struct sqlite3_context sqlite3_context;
|
|
2447
2524
|
** KEYWORDS: {SQL parameter} {SQL parameters} {parameter binding}
|
2448
2525
|
**
|
2449
2526
|
** In the SQL strings input to [sqlite3_prepare_v2()] and its variants,
|
2450
|
-
** literals may be replaced by a [parameter]
|
2527
|
+
** literals may be replaced by a [parameter] that matches one of following
|
2528
|
+
** templates:
|
2451
2529
|
**
|
2452
2530
|
** <ul>
|
2453
2531
|
** <li> ?
|
@@ -2457,8 +2535,8 @@ typedef struct sqlite3_context sqlite3_context;
|
|
2457
2535
|
** <li> $VVV
|
2458
2536
|
** </ul>
|
2459
2537
|
**
|
2460
|
-
** In the
|
2461
|
-
** and VVV
|
2538
|
+
** In the templates above, NNN represents an integer literal,
|
2539
|
+
** and VVV represents an alphanumeric identifer. The values of these
|
2462
2540
|
** parameters (also called "host parameter names" or "SQL parameters")
|
2463
2541
|
** can be set using the sqlite3_bind_*() routines defined here.
|
2464
2542
|
**
|
@@ -3110,7 +3188,7 @@ SQLITE_API int sqlite3_reset(sqlite3_stmt *pStmt);
|
|
3110
3188
|
** [SQLITE_UTF8 | text encoding] this SQL function prefers for
|
3111
3189
|
** its parameters. Any SQL function implementation should be able to work
|
3112
3190
|
** work with UTF-8, UTF-16le, or UTF-16be. But some implementations may be
|
3113
|
-
** more efficient with one encoding than another.
|
3191
|
+
** more efficient with one encoding than another. An application may
|
3114
3192
|
** invoke sqlite3_create_function() or sqlite3_create_function16() multiple
|
3115
3193
|
** times with the same function but with different values of eTextRep.
|
3116
3194
|
** When multiple implementations of the same function are available, SQLite
|
@@ -3132,7 +3210,7 @@ SQLITE_API int sqlite3_reset(sqlite3_stmt *pStmt);
|
|
3132
3210
|
** It is permitted to register multiple implementations of the same
|
3133
3211
|
** functions with the same name but with either differing numbers of
|
3134
3212
|
** arguments or differing preferred text encodings. SQLite will use
|
3135
|
-
** the implementation most closely matches the way in which the
|
3213
|
+
** the implementation that most closely matches the way in which the
|
3136
3214
|
** SQL function is used. A function implementation with a non-negative
|
3137
3215
|
** nArg parameter is a better match than a function implementation with
|
3138
3216
|
** a negative nArg. A function where the preferred text encoding
|
@@ -3480,10 +3558,11 @@ typedef void (*sqlite3_destructor_type)(void*);
|
|
3480
3558
|
** or sqlite3_result_blob is a non-NULL pointer, then SQLite calls that
|
3481
3559
|
** function as the destructor on the text or BLOB result when it has
|
3482
3560
|
** finished using that result.
|
3483
|
-
** If the 4th parameter to the sqlite3_result_text* interfaces or
|
3561
|
+
** If the 4th parameter to the sqlite3_result_text* interfaces or to
|
3484
3562
|
** sqlite3_result_blob is the special constant SQLITE_STATIC, then SQLite
|
3485
3563
|
** assumes that the text or BLOB result is in constant space and does not
|
3486
|
-
** copy the
|
3564
|
+
** copy the content of the parameter nor call a destructor on the content
|
3565
|
+
** when it has finished using that result.
|
3487
3566
|
** If the 4th parameter to the sqlite3_result_text* interfaces
|
3488
3567
|
** or sqlite3_result_blob is the special constant SQLITE_TRANSIENT
|
3489
3568
|
** then SQLite makes a copy of the result into space obtained from
|
@@ -4433,6 +4512,9 @@ typedef struct sqlite3_blob sqlite3_blob;
|
|
4433
4512
|
**
|
4434
4513
|
** If the flags parameter is non-zero, then the BLOB is opened for read
|
4435
4514
|
** and write access. If it is zero, the BLOB is opened for read access.
|
4515
|
+
** It is not possible to open a column that is part of an index or primary
|
4516
|
+
** key for writing. ^If [foreign key constraints] are enabled, it is
|
4517
|
+
** not possible to open a column that is part of a [child key] for writing.
|
4436
4518
|
**
|
4437
4519
|
** Note that the database name is not the filename that contains
|
4438
4520
|
** the database but rather the symbolic name of the database that
|
@@ -4462,7 +4544,7 @@ typedef struct sqlite3_blob sqlite3_blob;
|
|
4462
4544
|
**
|
4463
4545
|
** Use the [sqlite3_blob_bytes()] interface to determine the size of
|
4464
4546
|
** the opened blob. The size of a blob may not be changed by this
|
4465
|
-
**
|
4547
|
+
** interface. Use the [UPDATE] SQL command to change the size of a
|
4466
4548
|
** blob.
|
4467
4549
|
**
|
4468
4550
|
** The [sqlite3_bind_zeroblob()] and [sqlite3_result_zeroblob()] interfaces
|
@@ -4702,7 +4784,7 @@ SQLITE_API int sqlite3_vfs_unregister(sqlite3_vfs*);
|
|
4702
4784
|
** might return such a mutex in response to SQLITE_MUTEX_FAST.
|
4703
4785
|
**
|
4704
4786
|
** {H17017} The other allowed parameters to sqlite3_mutex_alloc() each return
|
4705
|
-
** a pointer to a static preexisting mutex. {END}
|
4787
|
+
** a pointer to a static preexisting mutex. {END} Six static mutexes are
|
4706
4788
|
** used by the current version of SQLite. Future versions of SQLite
|
4707
4789
|
** may add additional static mutexes. Static mutexes are for internal
|
4708
4790
|
** use by SQLite only. Applications that use SQLite mutexes should
|
@@ -4808,6 +4890,21 @@ SQLITE_API void sqlite3_mutex_leave(sqlite3_mutex*);
|
|
4808
4890
|
** of passing a NULL pointer instead of a valid mutex handle are undefined
|
4809
4891
|
** (i.e. it is acceptable to provide an implementation that segfaults if
|
4810
4892
|
** it is passed a NULL pointer).
|
4893
|
+
**
|
4894
|
+
** The xMutexInit() method must be threadsafe. It must be harmless to
|
4895
|
+
** invoke xMutexInit() mutiple times within the same process and without
|
4896
|
+
** intervening calls to xMutexEnd(). Second and subsequent calls to
|
4897
|
+
** xMutexInit() must be no-ops.
|
4898
|
+
**
|
4899
|
+
** xMutexInit() must not use SQLite memory allocation ([sqlite3_malloc()]
|
4900
|
+
** and its associates). Similarly, xMutexAlloc() must not use SQLite memory
|
4901
|
+
** allocation for a static mutex. However xMutexAlloc() may use SQLite
|
4902
|
+
** memory allocation for a fast or recursive mutex.
|
4903
|
+
**
|
4904
|
+
** SQLite will invoke the xMutexEnd() method when [sqlite3_shutdown()] is
|
4905
|
+
** called, but only if the prior call to xMutexInit returned SQLITE_OK.
|
4906
|
+
** If xMutexInit fails in any way, it is expected to clean up after itself
|
4907
|
+
** prior to returning.
|
4811
4908
|
*/
|
4812
4909
|
typedef struct sqlite3_mutex_methods sqlite3_mutex_methods;
|
4813
4910
|
struct sqlite3_mutex_methods {
|
@@ -4973,7 +5070,7 @@ SQLITE_API int sqlite3_test_control(int op, ...);
|
|
4973
5070
|
** This routine returns SQLITE_OK on success and a non-zero
|
4974
5071
|
** [error code] on failure.
|
4975
5072
|
**
|
4976
|
-
** This routine is threadsafe but is not atomic. This routine can
|
5073
|
+
** This routine is threadsafe but is not atomic. This routine can be
|
4977
5074
|
** called while other threads are running the same or different SQLite
|
4978
5075
|
** interfaces. However the values returned in *pCurrent and
|
4979
5076
|
** *pHighwater reflect the status of SQLite at different points in time
|
@@ -5096,7 +5193,14 @@ SQLITE_API SQLITE_EXPERIMENTAL int sqlite3_db_status(sqlite3*, int op, int *pCur
|
|
5096
5193
|
** CAPI3REF: Status Parameters for database connections {H17520} <H17500>
|
5097
5194
|
** EXPERIMENTAL
|
5098
5195
|
**
|
5099
|
-
**
|
5196
|
+
** These constants are the available integer "verbs" that can be passed as
|
5197
|
+
** the second argument to the [sqlite3_db_status()] interface.
|
5198
|
+
**
|
5199
|
+
** New verbs may be added in future releases of SQLite. Existing verbs
|
5200
|
+
** might be discontinued. Applications should check the return code from
|
5201
|
+
** [sqlite3_db_status()] to make sure that the call worked.
|
5202
|
+
** The [sqlite3_db_status()] interface will return a non-zero error code
|
5203
|
+
** if a discontinued or unsupported verb is invoked.
|
5100
5204
|
**
|
5101
5205
|
** <dl>
|
5102
5206
|
** <dt>SQLITE_DBSTATUS_LOOKASIDE_USED</dt>
|
@@ -5174,95 +5278,109 @@ typedef struct sqlite3_pcache sqlite3_pcache;
|
|
5174
5278
|
|
5175
5279
|
/*
|
5176
5280
|
** CAPI3REF: Application Defined Page Cache.
|
5281
|
+
** KEYWORDS: {page cache}
|
5177
5282
|
** EXPERIMENTAL
|
5178
5283
|
**
|
5179
5284
|
** The [sqlite3_config]([SQLITE_CONFIG_PCACHE], ...) interface can
|
5180
5285
|
** register an alternative page cache implementation by passing in an
|
5181
5286
|
** instance of the sqlite3_pcache_methods structure. The majority of the
|
5182
|
-
** heap memory used by
|
5287
|
+
** heap memory used by SQLite is used by the page cache to cache data read
|
5183
5288
|
** from, or ready to be written to, the database file. By implementing a
|
5184
5289
|
** custom page cache using this API, an application can control more
|
5185
|
-
** precisely the amount of memory consumed by
|
5186
|
-
**
|
5290
|
+
** precisely the amount of memory consumed by SQLite, the way in which
|
5291
|
+
** that memory is allocated and released, and the policies used to
|
5187
5292
|
** determine exactly which parts of a database file are cached and for
|
5188
5293
|
** how long.
|
5189
5294
|
**
|
5190
|
-
** The contents of the structure are copied to an
|
5191
|
-
** within the call to [sqlite3_config].
|
5295
|
+
** The contents of the sqlite3_pcache_methods structure are copied to an
|
5296
|
+
** internal buffer by SQLite within the call to [sqlite3_config]. Hence
|
5297
|
+
** the application may discard the parameter after the call to
|
5298
|
+
** [sqlite3_config()] returns.
|
5192
5299
|
**
|
5193
5300
|
** The xInit() method is called once for each call to [sqlite3_initialize()]
|
5194
5301
|
** (usually only once during the lifetime of the process). It is passed
|
5195
5302
|
** a copy of the sqlite3_pcache_methods.pArg value. It can be used to set
|
5196
5303
|
** up global structures and mutexes required by the custom page cache
|
5197
|
-
** implementation.
|
5198
|
-
**
|
5199
|
-
**
|
5304
|
+
** implementation.
|
5305
|
+
**
|
5306
|
+
** The xShutdown() method is called from within [sqlite3_shutdown()],
|
5307
|
+
** if the application invokes this API. It can be used to clean up
|
5308
|
+
** any outstanding resources before process shutdown, if required.
|
5309
|
+
**
|
5310
|
+
** SQLite holds a [SQLITE_MUTEX_RECURSIVE] mutex when it invokes
|
5311
|
+
** the xInit method, so the xInit method need not be threadsafe. The
|
5312
|
+
** xShutdown method is only called from [sqlite3_shutdown()] so it does
|
5313
|
+
** not need to be threadsafe either. All other methods must be threadsafe
|
5314
|
+
** in multithreaded applications.
|
5200
5315
|
**
|
5201
|
-
**
|
5316
|
+
** SQLite will never invoke xInit() more than once without an intervening
|
5317
|
+
** call to xShutdown().
|
5318
|
+
**
|
5319
|
+
** The xCreate() method is used to construct a new cache instance. SQLite
|
5320
|
+
** will typically create one cache instance for each open database file,
|
5321
|
+
** though this is not guaranteed. The
|
5202
5322
|
** first parameter, szPage, is the size in bytes of the pages that must
|
5203
|
-
** be allocated by the cache.
|
5204
|
-
**
|
5205
|
-
**
|
5323
|
+
** be allocated by the cache. szPage will not be a power of two. szPage
|
5324
|
+
** will the page size of the database file that is to be cached plus an
|
5325
|
+
** increment (here called "R") of about 100 or 200. SQLite will use the
|
5326
|
+
** extra R bytes on each page to store metadata about the underlying
|
5327
|
+
** database page on disk. The value of R depends
|
5328
|
+
** on the SQLite version, the target platform, and how SQLite was compiled.
|
5329
|
+
** R is constant for a particular build of SQLite. The second argument to
|
5330
|
+
** xCreate(), bPurgeable, is true if the cache being created will
|
5331
|
+
** be used to cache database pages of a file stored on disk, or
|
5206
5332
|
** false if it is used for an in-memory database. The cache implementation
|
5207
|
-
** does not have to do anything special based
|
5208
|
-
** it is purely advisory.
|
5333
|
+
** does not have to do anything special based with the value of bPurgeable;
|
5334
|
+
** it is purely advisory. On a cache where bPurgeable is false, SQLite will
|
5335
|
+
** never invoke xUnpin() except to deliberately delete a page.
|
5336
|
+
** In other words, a cache created with bPurgeable set to false will
|
5337
|
+
** never contain any unpinned pages.
|
5209
5338
|
**
|
5210
5339
|
** The xCachesize() method may be called at any time by SQLite to set the
|
5211
5340
|
** suggested maximum cache-size (number of pages stored by) the cache
|
5212
5341
|
** instance passed as the first argument. This is the value configured using
|
5213
5342
|
** the SQLite "[PRAGMA cache_size]" command. As with the bPurgeable parameter,
|
5214
|
-
** the implementation is not required to do anything
|
5215
|
-
** value
|
5343
|
+
** the implementation is not required to do anything with this
|
5344
|
+
** value; it is advisory only.
|
5216
5345
|
**
|
5217
5346
|
** The xPagecount() method should return the number of pages currently
|
5218
|
-
** stored in the cache
|
5347
|
+
** stored in the cache.
|
5219
5348
|
**
|
5220
5349
|
** The xFetch() method is used to fetch a page and return a pointer to it.
|
5221
5350
|
** A 'page', in this context, is a buffer of szPage bytes aligned at an
|
5222
5351
|
** 8-byte boundary. The page to be fetched is determined by the key. The
|
5223
5352
|
** mimimum key value is 1. After it has been retrieved using xFetch, the page
|
5224
|
-
** is considered to be pinned.
|
5353
|
+
** is considered to be "pinned".
|
5225
5354
|
**
|
5226
|
-
** If the requested page is already in the page cache, then
|
5227
|
-
**
|
5228
|
-
** page is not already in the cache, then the
|
5229
|
-
** cache is determined by the value of the
|
5230
|
-
** to xFetch, according to the following table:
|
5355
|
+
** If the requested page is already in the page cache, then the page cache
|
5356
|
+
** implementation must return a pointer to the page buffer with its content
|
5357
|
+
** intact. If the requested page is not already in the cache, then the
|
5358
|
+
** behavior of the cache implementation is determined by the value of the
|
5359
|
+
** createFlag parameter passed to xFetch, according to the following table:
|
5231
5360
|
**
|
5232
5361
|
** <table border=1 width=85% align=center>
|
5233
|
-
**
|
5234
|
-
**
|
5235
|
-
**
|
5236
|
-
**
|
5237
|
-
**
|
5238
|
-
**
|
5239
|
-
** cache implementation has two choices: it can return NULL,
|
5240
|
-
** in which case SQLite will attempt to unpin one or more
|
5241
|
-
** pages before re-requesting the same page, or it can
|
5242
|
-
** allocate a new page and return a pointer to it. If a new
|
5243
|
-
** page is allocated, then the first sizeof(void*) bytes of
|
5244
|
-
** it (at least) must be zeroed before it is returned.
|
5245
|
-
** <tr><td>2<td>If createFlag is set to 2, then SQLite is not holding any
|
5246
|
-
** pinned pages associated with the specific cache passed
|
5247
|
-
** as the first argument to xFetch() that can be unpinned. The
|
5248
|
-
** cache implementation should attempt to allocate a new
|
5249
|
-
** cache entry and return a pointer to it. Again, the first
|
5250
|
-
** sizeof(void*) bytes of the page should be zeroed before
|
5251
|
-
** it is returned. If the xFetch() method returns NULL when
|
5252
|
-
** createFlag==2, SQLite assumes that a memory allocation
|
5253
|
-
** failed and returns SQLITE_NOMEM to the user.
|
5362
|
+
** <tr><th> createFlag <th> Behaviour when page is not already in cache
|
5363
|
+
** <tr><td> 0 <td> Do not allocate a new page. Return NULL.
|
5364
|
+
** <tr><td> 1 <td> Allocate a new page if it easy and convenient to do so.
|
5365
|
+
** Otherwise return NULL.
|
5366
|
+
** <tr><td> 2 <td> Make every effort to allocate a new page. Only return
|
5367
|
+
** NULL if allocating a new page is effectively impossible.
|
5254
5368
|
** </table>
|
5255
5369
|
**
|
5370
|
+
** SQLite will normally invoke xFetch() with a createFlag of 0 or 1. If
|
5371
|
+
** a call to xFetch() with createFlag==1 returns NULL, then SQLite will
|
5372
|
+
** attempt to unpin one or more cache pages by spilling the content of
|
5373
|
+
** pinned pages to disk and synching the operating system disk cache. After
|
5374
|
+
** attempting to unpin pages, the xFetch() method will be invoked again with
|
5375
|
+
** a createFlag of 2.
|
5376
|
+
**
|
5256
5377
|
** xUnpin() is called by SQLite with a pointer to a currently pinned page
|
5257
5378
|
** as its second argument. If the third parameter, discard, is non-zero,
|
5258
5379
|
** then the page should be evicted from the cache. In this case SQLite
|
5259
5380
|
** assumes that the next time the page is retrieved from the cache using
|
5260
5381
|
** the xFetch() method, it will be zeroed. If the discard parameter is
|
5261
5382
|
** zero, then the page is considered to be unpinned. The cache implementation
|
5262
|
-
** may choose to
|
5263
|
-
** SQLite assumes that next time the page is retrieved from the cache
|
5264
|
-
** it will either be zeroed, or contain the same data that it did when it
|
5265
|
-
** was unpinned.
|
5383
|
+
** may choose to evict unpinned pages at any time.
|
5266
5384
|
**
|
5267
5385
|
** The cache is not required to perform any reference counting. A single
|
5268
5386
|
** call to xUnpin() unpins the page regardless of the number of prior calls
|