cordova-sqlite-evmax-build-free 0.0.4 → 0.0.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -146,9 +146,9 @@ extern "C" {
146
146
  ** [sqlite3_libversion_number()], [sqlite3_sourceid()],
147
147
  ** [sqlite_version()] and [sqlite_source_id()].
148
148
  */
149
- #define SQLITE_VERSION "3.37.2"
150
- #define SQLITE_VERSION_NUMBER 3037002
151
- #define SQLITE_SOURCE_ID "2022-01-06 13:25:41 872ba256cbf61d9290b571c0e6d82a20c224ca3ad82971edc46b29818d5d17a0"
149
+ #define SQLITE_VERSION "3.38.5"
150
+ #define SQLITE_VERSION_NUMBER 3038005
151
+ #define SQLITE_SOURCE_ID "2022-05-06 15:25:27 78d9c993d404cdfaa7fdd2973fa1052e3da9f66215cff9c5540ebe55c407d9fe"
152
152
 
153
153
  /*
154
154
  ** CAPI3REF: Run-Time Library Version Numbers
@@ -566,7 +566,7 @@ SQLITE_API int sqlite3_exec(
566
566
  #define SQLITE_WARNING_AUTOINDEX (SQLITE_WARNING | (1<<8))
567
567
  #define SQLITE_AUTH_USER (SQLITE_AUTH | (1<<8))
568
568
  #define SQLITE_OK_LOAD_PERMANENTLY (SQLITE_OK | (1<<8))
569
- #define SQLITE_OK_SYMLINK (SQLITE_OK | (2<<8))
569
+ #define SQLITE_OK_SYMLINK (SQLITE_OK | (2<<8)) /* internal use only */
570
570
 
571
571
  /*
572
572
  ** CAPI3REF: Flags For File Open Operations
@@ -3824,13 +3824,14 @@ SQLITE_API void sqlite3_free_filename(char*);
3824
3824
  ** sqlite3_extended_errcode() might change with each API call.
3825
3825
  ** Except, there are some interfaces that are guaranteed to never
3826
3826
  ** change the value of the error code. The error-code preserving
3827
- ** interfaces are:
3827
+ ** interfaces include the following:
3828
3828
  **
3829
3829
  ** <ul>
3830
3830
  ** <li> sqlite3_errcode()
3831
3831
  ** <li> sqlite3_extended_errcode()
3832
3832
  ** <li> sqlite3_errmsg()
3833
3833
  ** <li> sqlite3_errmsg16()
3834
+ ** <li> sqlite3_error_offset()
3834
3835
  ** </ul>
3835
3836
  **
3836
3837
  ** ^The sqlite3_errmsg() and sqlite3_errmsg16() return English-language
@@ -3845,6 +3846,13 @@ SQLITE_API void sqlite3_free_filename(char*);
3845
3846
  ** ^(Memory to hold the error message string is managed internally
3846
3847
  ** and must not be freed by the application)^.
3847
3848
  **
3849
+ ** ^If the most recent error references a specific token in the input
3850
+ ** SQL, the sqlite3_error_offset() interface returns the byte offset
3851
+ ** of the start of that token. ^The byte offset returned by
3852
+ ** sqlite3_error_offset() assumes that the input SQL is UTF8.
3853
+ ** ^If the most recent error does not reference a specific token in the input
3854
+ ** SQL, then the sqlite3_error_offset() function returns -1.
3855
+ **
3848
3856
  ** When the serialized [threading mode] is in use, it might be the
3849
3857
  ** case that a second error occurs on a separate thread in between
3850
3858
  ** the time of the first error and the call to these interfaces.
@@ -3864,6 +3872,7 @@ SQLITE_API int sqlite3_extended_errcode(sqlite3 *db);
3864
3872
  SQLITE_API const char *sqlite3_errmsg(sqlite3*);
3865
3873
  SQLITE_API const void *sqlite3_errmsg16(sqlite3*);
3866
3874
  SQLITE_API const char *sqlite3_errstr(int);
3875
+ SQLITE_API int sqlite3_error_offset(sqlite3 *db);
3867
3876
 
3868
3877
  /*
3869
3878
  ** CAPI3REF: Prepared Statement Object
@@ -4275,6 +4284,10 @@ SQLITE_API const char *sqlite3_normalized_sql(sqlite3_stmt *pStmt);
4275
4284
  ** be false. ^Similarly, a CREATE TABLE IF NOT EXISTS statement is a
4276
4285
  ** read-only no-op if the table already exists, but
4277
4286
  ** sqlite3_stmt_readonly() still returns false for such a statement.
4287
+ **
4288
+ ** ^If prepared statement X is an [EXPLAIN] or [EXPLAIN QUERY PLAN]
4289
+ ** statement, then sqlite3_stmt_readonly(X) returns the same value as
4290
+ ** if the EXPLAIN or EXPLAIN QUERY PLAN prefix were omitted.
4278
4291
  */
4279
4292
  SQLITE_API int sqlite3_stmt_readonly(sqlite3_stmt *pStmt);
4280
4293
 
@@ -4343,6 +4356,8 @@ SQLITE_API int sqlite3_stmt_busy(sqlite3_stmt*);
4343
4356
  **
4344
4357
  ** ^The sqlite3_value objects that are passed as parameters into the
4345
4358
  ** implementation of [application-defined SQL functions] are protected.
4359
+ ** ^The sqlite3_value objects returned by [sqlite3_vtab_rhs_value()]
4360
+ ** are protected.
4346
4361
  ** ^The sqlite3_value object returned by
4347
4362
  ** [sqlite3_column_value()] is unprotected.
4348
4363
  ** Unprotected sqlite3_value objects may only be used as arguments
@@ -4964,6 +4979,10 @@ SQLITE_API int sqlite3_data_count(sqlite3_stmt *pStmt);
4964
4979
  ** even empty strings, are always zero-terminated. ^The return
4965
4980
  ** value from sqlite3_column_blob() for a zero-length BLOB is a NULL pointer.
4966
4981
  **
4982
+ ** ^Strings returned by sqlite3_column_text16() always have the endianness
4983
+ ** which is native to the platform, regardless of the text encoding set
4984
+ ** for the database.
4985
+ **
4967
4986
  ** <b>Warning:</b> ^The object returned by [sqlite3_column_value()] is an
4968
4987
  ** [unprotected sqlite3_value] object. In a multithreaded environment,
4969
4988
  ** an unprotected sqlite3_value object may only be used safely with
@@ -4977,7 +4996,7 @@ SQLITE_API int sqlite3_data_count(sqlite3_stmt *pStmt);
4977
4996
  ** [application-defined SQL functions] or [virtual tables], not within
4978
4997
  ** top-level application code.
4979
4998
  **
4980
- ** The these routines may attempt to convert the datatype of the result.
4999
+ ** These routines may attempt to convert the datatype of the result.
4981
5000
  ** ^For example, if the internal representation is FLOAT and a text result
4982
5001
  ** is requested, [sqlite3_snprintf()] is used internally to perform the
4983
5002
  ** conversion automatically. ^(The following table details the conversions
@@ -5002,7 +5021,7 @@ SQLITE_API int sqlite3_data_count(sqlite3_stmt *pStmt);
5002
5021
  ** <tr><td> TEXT <td> BLOB <td> No change
5003
5022
  ** <tr><td> BLOB <td> INTEGER <td> [CAST] to INTEGER
5004
5023
  ** <tr><td> BLOB <td> FLOAT <td> [CAST] to REAL
5005
- ** <tr><td> BLOB <td> TEXT <td> Add a zero terminator if needed
5024
+ ** <tr><td> BLOB <td> TEXT <td> [CAST] to TEXT, ensure zero terminator
5006
5025
  ** </table>
5007
5026
  ** </blockquote>)^
5008
5027
  **
@@ -7122,24 +7141,56 @@ struct sqlite3_index_info {
7122
7141
  **
7123
7142
  ** These macros define the allowed values for the
7124
7143
  ** [sqlite3_index_info].aConstraint[].op field. Each value represents
7125
- ** an operator that is part of a constraint term in the wHERE clause of
7144
+ ** an operator that is part of a constraint term in the WHERE clause of
7126
7145
  ** a query that uses a [virtual table].
7127
- */
7128
- #define SQLITE_INDEX_CONSTRAINT_EQ 2
7129
- #define SQLITE_INDEX_CONSTRAINT_GT 4
7130
- #define SQLITE_INDEX_CONSTRAINT_LE 8
7131
- #define SQLITE_INDEX_CONSTRAINT_LT 16
7132
- #define SQLITE_INDEX_CONSTRAINT_GE 32
7133
- #define SQLITE_INDEX_CONSTRAINT_MATCH 64
7134
- #define SQLITE_INDEX_CONSTRAINT_LIKE 65
7135
- #define SQLITE_INDEX_CONSTRAINT_GLOB 66
7136
- #define SQLITE_INDEX_CONSTRAINT_REGEXP 67
7137
- #define SQLITE_INDEX_CONSTRAINT_NE 68
7138
- #define SQLITE_INDEX_CONSTRAINT_ISNOT 69
7139
- #define SQLITE_INDEX_CONSTRAINT_ISNOTNULL 70
7140
- #define SQLITE_INDEX_CONSTRAINT_ISNULL 71
7141
- #define SQLITE_INDEX_CONSTRAINT_IS 72
7142
- #define SQLITE_INDEX_CONSTRAINT_FUNCTION 150
7146
+ **
7147
+ ** ^The left-hand operand of the operator is given by the corresponding
7148
+ ** aConstraint[].iColumn field. ^An iColumn of -1 indicates the left-hand
7149
+ ** operand is the rowid.
7150
+ ** The SQLITE_INDEX_CONSTRAINT_LIMIT and SQLITE_INDEX_CONSTRAINT_OFFSET
7151
+ ** operators have no left-hand operand, and so for those operators the
7152
+ ** corresponding aConstraint[].iColumn is meaningless and should not be
7153
+ ** used.
7154
+ **
7155
+ ** All operator values from SQLITE_INDEX_CONSTRAINT_FUNCTION through
7156
+ ** value 255 are reserved to represent functions that are overloaded
7157
+ ** by the [xFindFunction|xFindFunction method] of the virtual table
7158
+ ** implementation.
7159
+ **
7160
+ ** The right-hand operands for each constraint might be accessible using
7161
+ ** the [sqlite3_vtab_rhs_value()] interface. Usually the right-hand
7162
+ ** operand is only available if it appears as a single constant literal
7163
+ ** in the input SQL. If the right-hand operand is another column or an
7164
+ ** expression (even a constant expression) or a parameter, then the
7165
+ ** sqlite3_vtab_rhs_value() probably will not be able to extract it.
7166
+ ** ^The SQLITE_INDEX_CONSTRAINT_ISNULL and
7167
+ ** SQLITE_INDEX_CONSTRAINT_ISNOTNULL operators have no right-hand operand
7168
+ ** and hence calls to sqlite3_vtab_rhs_value() for those operators will
7169
+ ** always return SQLITE_NOTFOUND.
7170
+ **
7171
+ ** The collating sequence to be used for comparison can be found using
7172
+ ** the [sqlite3_vtab_collation()] interface. For most real-world virtual
7173
+ ** tables, the collating sequence of constraints does not matter (for example
7174
+ ** because the constraints are numeric) and so the sqlite3_vtab_collation()
7175
+ ** interface is no commonly needed.
7176
+ */
7177
+ #define SQLITE_INDEX_CONSTRAINT_EQ 2
7178
+ #define SQLITE_INDEX_CONSTRAINT_GT 4
7179
+ #define SQLITE_INDEX_CONSTRAINT_LE 8
7180
+ #define SQLITE_INDEX_CONSTRAINT_LT 16
7181
+ #define SQLITE_INDEX_CONSTRAINT_GE 32
7182
+ #define SQLITE_INDEX_CONSTRAINT_MATCH 64
7183
+ #define SQLITE_INDEX_CONSTRAINT_LIKE 65
7184
+ #define SQLITE_INDEX_CONSTRAINT_GLOB 66
7185
+ #define SQLITE_INDEX_CONSTRAINT_REGEXP 67
7186
+ #define SQLITE_INDEX_CONSTRAINT_NE 68
7187
+ #define SQLITE_INDEX_CONSTRAINT_ISNOT 69
7188
+ #define SQLITE_INDEX_CONSTRAINT_ISNOTNULL 70
7189
+ #define SQLITE_INDEX_CONSTRAINT_ISNULL 71
7190
+ #define SQLITE_INDEX_CONSTRAINT_IS 72
7191
+ #define SQLITE_INDEX_CONSTRAINT_LIMIT 73
7192
+ #define SQLITE_INDEX_CONSTRAINT_OFFSET 74
7193
+ #define SQLITE_INDEX_CONSTRAINT_FUNCTION 150
7143
7194
 
7144
7195
  /*
7145
7196
  ** CAPI3REF: Register A Virtual Table Implementation
@@ -7168,7 +7219,7 @@ struct sqlite3_index_info {
7168
7219
  ** destructor.
7169
7220
  **
7170
7221
  ** ^If the third parameter (the pointer to the sqlite3_module object) is
7171
- ** NULL then no new module is create and any existing modules with the
7222
+ ** NULL then no new module is created and any existing modules with the
7172
7223
  ** same name are dropped.
7173
7224
  **
7174
7225
  ** See also: [sqlite3_drop_modules()]
@@ -7944,7 +7995,8 @@ SQLITE_API int sqlite3_test_control(int op, ...);
7944
7995
  #define SQLITE_TESTCTRL_SEEK_COUNT 30
7945
7996
  #define SQLITE_TESTCTRL_TRACEFLAGS 31
7946
7997
  #define SQLITE_TESTCTRL_TUNE 32
7947
- #define SQLITE_TESTCTRL_LAST 32 /* Largest TESTCTRL */
7998
+ #define SQLITE_TESTCTRL_LOGEST 33
7999
+ #define SQLITE_TESTCTRL_LAST 33 /* Largest TESTCTRL */
7948
8000
 
7949
8001
  /*
7950
8002
  ** CAPI3REF: SQL Keyword Checking
@@ -8467,6 +8519,16 @@ SQLITE_API int sqlite3_stmt_status(sqlite3_stmt*, int op,int resetFlg);
8467
8519
  ** The counter is incremented on the first [sqlite3_step()] call of each
8468
8520
  ** cycle.
8469
8521
  **
8522
+ ** [[SQLITE_STMTSTATUS_FILTER_MISS]]
8523
+ ** [[SQLITE_STMTSTATUS_FILTER HIT]]
8524
+ ** <dt>SQLITE_STMTSTATUS_FILTER_HIT<br>
8525
+ ** SQLITE_STMTSTATUS_FILTER_MISS</dt>
8526
+ ** <dd>^SQLITE_STMTSTATUS_FILTER_HIT is the number of times that a join
8527
+ ** step was bypassed because a Bloom filter returned not-found. The
8528
+ ** corresponding SQLITE_STMTSTATUS_FILTER_MISS value is the number of
8529
+ ** times that the Bloom filter returned a find, and thus the join step
8530
+ ** had to be processed as normal.
8531
+ **
8470
8532
  ** [[SQLITE_STMTSTATUS_MEMUSED]] <dt>SQLITE_STMTSTATUS_MEMUSED</dt>
8471
8533
  ** <dd>^This is the approximate number of bytes of heap memory
8472
8534
  ** used to store the prepared statement. ^This value is not actually
@@ -8481,6 +8543,8 @@ SQLITE_API int sqlite3_stmt_status(sqlite3_stmt*, int op,int resetFlg);
8481
8543
  #define SQLITE_STMTSTATUS_VM_STEP 4
8482
8544
  #define SQLITE_STMTSTATUS_REPREPARE 5
8483
8545
  #define SQLITE_STMTSTATUS_RUN 6
8546
+ #define SQLITE_STMTSTATUS_FILTER_MISS 7
8547
+ #define SQLITE_STMTSTATUS_FILTER_HIT 8
8484
8548
  #define SQLITE_STMTSTATUS_MEMUSED 99
8485
8549
 
8486
8550
  /*
@@ -9449,19 +9513,269 @@ SQLITE_API int sqlite3_vtab_nochange(sqlite3_context*);
9449
9513
 
9450
9514
  /*
9451
9515
  ** CAPI3REF: Determine The Collation For a Virtual Table Constraint
9516
+ ** METHOD: sqlite3_index_info
9452
9517
  **
9453
9518
  ** This function may only be called from within a call to the [xBestIndex]
9454
- ** method of a [virtual table].
9519
+ ** method of a [virtual table]. This function returns a pointer to a string
9520
+ ** that is the name of the appropriate collation sequence to use for text
9521
+ ** comparisons on the constraint identified by its arguments.
9522
+ **
9523
+ ** The first argument must be the pointer to the [sqlite3_index_info] object
9524
+ ** that is the first parameter to the xBestIndex() method. The second argument
9525
+ ** must be an index into the aConstraint[] array belonging to the
9526
+ ** sqlite3_index_info structure passed to xBestIndex.
9527
+ **
9528
+ ** Important:
9529
+ ** The first parameter must be the same pointer that is passed into the
9530
+ ** xBestMethod() method. The first parameter may not be a pointer to a
9531
+ ** different [sqlite3_index_info] object, even an exact copy.
9532
+ **
9533
+ ** The return value is computed as follows:
9455
9534
  **
9456
- ** The first argument must be the sqlite3_index_info object that is the
9457
- ** first parameter to the xBestIndex() method. The second argument must be
9458
- ** an index into the aConstraint[] array belonging to the sqlite3_index_info
9459
- ** structure passed to xBestIndex. This function returns a pointer to a buffer
9460
- ** containing the name of the collation sequence for the corresponding
9461
- ** constraint.
9535
+ ** <ol>
9536
+ ** <li><p> If the constraint comes from a WHERE clause expression that contains
9537
+ ** a [COLLATE operator], then the name of the collation specified by
9538
+ ** that COLLATE operator is returned.
9539
+ ** <li><p> If there is no COLLATE operator, but the column that is the subject
9540
+ ** of the constraint specifies an alternative collating sequence via
9541
+ ** a [COLLATE clause] on the column definition within the CREATE TABLE
9542
+ ** statement that was passed into [sqlite3_declare_vtab()], then the
9543
+ ** name of that alternative collating sequence is returned.
9544
+ ** <li><p> Otherwise, "BINARY" is returned.
9545
+ ** </ol>
9462
9546
  */
9463
9547
  SQLITE_API SQLITE_EXPERIMENTAL const char *sqlite3_vtab_collation(sqlite3_index_info*,int);
9464
9548
 
9549
+ /*
9550
+ ** CAPI3REF: Determine if a virtual table query is DISTINCT
9551
+ ** METHOD: sqlite3_index_info
9552
+ **
9553
+ ** This API may only be used from within an [xBestIndex|xBestIndex method]
9554
+ ** of a [virtual table] implementation. The result of calling this
9555
+ ** interface from outside of xBestIndex() is undefined and probably harmful.
9556
+ **
9557
+ ** ^The sqlite3_vtab_distinct() interface returns an integer that is
9558
+ ** either 0, 1, or 2. The integer returned by sqlite3_vtab_distinct()
9559
+ ** gives the virtual table additional information about how the query
9560
+ ** planner wants the output to be ordered. As long as the virtual table
9561
+ ** can meet the ordering requirements of the query planner, it may set
9562
+ ** the "orderByConsumed" flag.
9563
+ **
9564
+ ** <ol><li value="0"><p>
9565
+ ** ^If the sqlite3_vtab_distinct() interface returns 0, that means
9566
+ ** that the query planner needs the virtual table to return all rows in the
9567
+ ** sort order defined by the "nOrderBy" and "aOrderBy" fields of the
9568
+ ** [sqlite3_index_info] object. This is the default expectation. If the
9569
+ ** virtual table outputs all rows in sorted order, then it is always safe for
9570
+ ** the xBestIndex method to set the "orderByConsumed" flag, regardless of
9571
+ ** the return value from sqlite3_vtab_distinct().
9572
+ ** <li value="1"><p>
9573
+ ** ^(If the sqlite3_vtab_distinct() interface returns 1, that means
9574
+ ** that the query planner does not need the rows to be returned in sorted order
9575
+ ** as long as all rows with the same values in all columns identified by the
9576
+ ** "aOrderBy" field are adjacent.)^ This mode is used when the query planner
9577
+ ** is doing a GROUP BY.
9578
+ ** <li value="2"><p>
9579
+ ** ^(If the sqlite3_vtab_distinct() interface returns 2, that means
9580
+ ** that the query planner does not need the rows returned in any particular
9581
+ ** order, as long as rows with the same values in all "aOrderBy" columns
9582
+ ** are adjacent.)^ ^(Furthermore, only a single row for each particular
9583
+ ** combination of values in the columns identified by the "aOrderBy" field
9584
+ ** needs to be returned.)^ ^It is always ok for two or more rows with the same
9585
+ ** values in all "aOrderBy" columns to be returned, as long as all such rows
9586
+ ** are adjacent. ^The virtual table may, if it chooses, omit extra rows
9587
+ ** that have the same value for all columns identified by "aOrderBy".
9588
+ ** ^However omitting the extra rows is optional.
9589
+ ** This mode is used for a DISTINCT query.
9590
+ ** </ol>
9591
+ **
9592
+ ** ^For the purposes of comparing virtual table output values to see if the
9593
+ ** values are same value for sorting purposes, two NULL values are considered
9594
+ ** to be the same. In other words, the comparison operator is "IS"
9595
+ ** (or "IS NOT DISTINCT FROM") and not "==".
9596
+ **
9597
+ ** If a virtual table implementation is unable to meet the requirements
9598
+ ** specified above, then it must not set the "orderByConsumed" flag in the
9599
+ ** [sqlite3_index_info] object or an incorrect answer may result.
9600
+ **
9601
+ ** ^A virtual table implementation is always free to return rows in any order
9602
+ ** it wants, as long as the "orderByConsumed" flag is not set. ^When the
9603
+ ** the "orderByConsumed" flag is unset, the query planner will add extra
9604
+ ** [bytecode] to ensure that the final results returned by the SQL query are
9605
+ ** ordered correctly. The use of the "orderByConsumed" flag and the
9606
+ ** sqlite3_vtab_distinct() interface is merely an optimization. ^Careful
9607
+ ** use of the sqlite3_vtab_distinct() interface and the "orderByConsumed"
9608
+ ** flag might help queries against a virtual table to run faster. Being
9609
+ ** overly aggressive and setting the "orderByConsumed" flag when it is not
9610
+ ** valid to do so, on the other hand, might cause SQLite to return incorrect
9611
+ ** results.
9612
+ */
9613
+ SQLITE_API int sqlite3_vtab_distinct(sqlite3_index_info*);
9614
+
9615
+ /*
9616
+ ** CAPI3REF: Identify and handle IN constraints in xBestIndex
9617
+ **
9618
+ ** This interface may only be used from within an
9619
+ ** [xBestIndex|xBestIndex() method] of a [virtual table] implementation.
9620
+ ** The result of invoking this interface from any other context is
9621
+ ** undefined and probably harmful.
9622
+ **
9623
+ ** ^(A constraint on a virtual table of the form
9624
+ ** "[IN operator|column IN (...)]" is
9625
+ ** communicated to the xBestIndex method as a
9626
+ ** [SQLITE_INDEX_CONSTRAINT_EQ] constraint.)^ If xBestIndex wants to use
9627
+ ** this constraint, it must set the corresponding
9628
+ ** aConstraintUsage[].argvIndex to a postive integer. ^(Then, under
9629
+ ** the usual mode of handling IN operators, SQLite generates [bytecode]
9630
+ ** that invokes the [xFilter|xFilter() method] once for each value
9631
+ ** on the right-hand side of the IN operator.)^ Thus the virtual table
9632
+ ** only sees a single value from the right-hand side of the IN operator
9633
+ ** at a time.
9634
+ **
9635
+ ** In some cases, however, it would be advantageous for the virtual
9636
+ ** table to see all values on the right-hand of the IN operator all at
9637
+ ** once. The sqlite3_vtab_in() interfaces facilitates this in two ways:
9638
+ **
9639
+ ** <ol>
9640
+ ** <li><p>
9641
+ ** ^A call to sqlite3_vtab_in(P,N,-1) will return true (non-zero)
9642
+ ** if and only if the [sqlite3_index_info|P->aConstraint][N] constraint
9643
+ ** is an [IN operator] that can be processed all at once. ^In other words,
9644
+ ** sqlite3_vtab_in() with -1 in the third argument is a mechanism
9645
+ ** by which the virtual table can ask SQLite if all-at-once processing
9646
+ ** of the IN operator is even possible.
9647
+ **
9648
+ ** <li><p>
9649
+ ** ^A call to sqlite3_vtab_in(P,N,F) with F==1 or F==0 indicates
9650
+ ** to SQLite that the virtual table does or does not want to process
9651
+ ** the IN operator all-at-once, respectively. ^Thus when the third
9652
+ ** parameter (F) is non-negative, this interface is the mechanism by
9653
+ ** which the virtual table tells SQLite how it wants to process the
9654
+ ** IN operator.
9655
+ ** </ol>
9656
+ **
9657
+ ** ^The sqlite3_vtab_in(P,N,F) interface can be invoked multiple times
9658
+ ** within the same xBestIndex method call. ^For any given P,N pair,
9659
+ ** the return value from sqlite3_vtab_in(P,N,F) will always be the same
9660
+ ** within the same xBestIndex call. ^If the interface returns true
9661
+ ** (non-zero), that means that the constraint is an IN operator
9662
+ ** that can be processed all-at-once. ^If the constraint is not an IN
9663
+ ** operator or cannot be processed all-at-once, then the interface returns
9664
+ ** false.
9665
+ **
9666
+ ** ^(All-at-once processing of the IN operator is selected if both of the
9667
+ ** following conditions are met:
9668
+ **
9669
+ ** <ol>
9670
+ ** <li><p> The P->aConstraintUsage[N].argvIndex value is set to a positive
9671
+ ** integer. This is how the virtual table tells SQLite that it wants to
9672
+ ** use the N-th constraint.
9673
+ **
9674
+ ** <li><p> The last call to sqlite3_vtab_in(P,N,F) for which F was
9675
+ ** non-negative had F>=1.
9676
+ ** </ol>)^
9677
+ **
9678
+ ** ^If either or both of the conditions above are false, then SQLite uses
9679
+ ** the traditional one-at-a-time processing strategy for the IN constraint.
9680
+ ** ^If both conditions are true, then the argvIndex-th parameter to the
9681
+ ** xFilter method will be an [sqlite3_value] that appears to be NULL,
9682
+ ** but which can be passed to [sqlite3_vtab_in_first()] and
9683
+ ** [sqlite3_vtab_in_next()] to find all values on the right-hand side
9684
+ ** of the IN constraint.
9685
+ */
9686
+ SQLITE_API int sqlite3_vtab_in(sqlite3_index_info*, int iCons, int bHandle);
9687
+
9688
+ /*
9689
+ ** CAPI3REF: Find all elements on the right-hand side of an IN constraint.
9690
+ **
9691
+ ** These interfaces are only useful from within the
9692
+ ** [xFilter|xFilter() method] of a [virtual table] implementation.
9693
+ ** The result of invoking these interfaces from any other context
9694
+ ** is undefined and probably harmful.
9695
+ **
9696
+ ** The X parameter in a call to sqlite3_vtab_in_first(X,P) or
9697
+ ** sqlite3_vtab_in_next(X,P) must be one of the parameters to the
9698
+ ** xFilter method which invokes these routines, and specifically
9699
+ ** a parameter that was previously selected for all-at-once IN constraint
9700
+ ** processing use the [sqlite3_vtab_in()] interface in the
9701
+ ** [xBestIndex|xBestIndex method]. ^(If the X parameter is not
9702
+ ** an xFilter argument that was selected for all-at-once IN constraint
9703
+ ** processing, then these routines return [SQLITE_MISUSE])^ or perhaps
9704
+ ** exhibit some other undefined or harmful behavior.
9705
+ **
9706
+ ** ^(Use these routines to access all values on the right-hand side
9707
+ ** of the IN constraint using code like the following:
9708
+ **
9709
+ ** <blockquote><pre>
9710
+ ** &nbsp; for(rc=sqlite3_vtab_in_first(pList, &pVal);
9711
+ ** &nbsp; rc==SQLITE_OK && pVal
9712
+ ** &nbsp; rc=sqlite3_vtab_in_next(pList, &pVal)
9713
+ ** &nbsp; ){
9714
+ ** &nbsp; // do something with pVal
9715
+ ** &nbsp; }
9716
+ ** &nbsp; if( rc!=SQLITE_OK ){
9717
+ ** &nbsp; // an error has occurred
9718
+ ** &nbsp; }
9719
+ ** </pre></blockquote>)^
9720
+ **
9721
+ ** ^On success, the sqlite3_vtab_in_first(X,P) and sqlite3_vtab_in_next(X,P)
9722
+ ** routines return SQLITE_OK and set *P to point to the first or next value
9723
+ ** on the RHS of the IN constraint. ^If there are no more values on the
9724
+ ** right hand side of the IN constraint, then *P is set to NULL and these
9725
+ ** routines return [SQLITE_DONE]. ^The return value might be
9726
+ ** some other value, such as SQLITE_NOMEM, in the event of a malfunction.
9727
+ **
9728
+ ** The *ppOut values returned by these routines are only valid until the
9729
+ ** next call to either of these routines or until the end of the xFilter
9730
+ ** method from which these routines were called. If the virtual table
9731
+ ** implementation needs to retain the *ppOut values for longer, it must make
9732
+ ** copies. The *ppOut values are [protected sqlite3_value|protected].
9733
+ */
9734
+ SQLITE_API int sqlite3_vtab_in_first(sqlite3_value *pVal, sqlite3_value **ppOut);
9735
+ SQLITE_API int sqlite3_vtab_in_next(sqlite3_value *pVal, sqlite3_value **ppOut);
9736
+
9737
+ /*
9738
+ ** CAPI3REF: Constraint values in xBestIndex()
9739
+ ** METHOD: sqlite3_index_info
9740
+ **
9741
+ ** This API may only be used from within the [xBestIndex|xBestIndex method]
9742
+ ** of a [virtual table] implementation. The result of calling this interface
9743
+ ** from outside of an xBestIndex method are undefined and probably harmful.
9744
+ **
9745
+ ** ^When the sqlite3_vtab_rhs_value(P,J,V) interface is invoked from within
9746
+ ** the [xBestIndex] method of a [virtual table] implementation, with P being
9747
+ ** a copy of the [sqlite3_index_info] object pointer passed into xBestIndex and
9748
+ ** J being a 0-based index into P->aConstraint[], then this routine
9749
+ ** attempts to set *V to the value of the right-hand operand of
9750
+ ** that constraint if the right-hand operand is known. ^If the
9751
+ ** right-hand operand is not known, then *V is set to a NULL pointer.
9752
+ ** ^The sqlite3_vtab_rhs_value(P,J,V) interface returns SQLITE_OK if
9753
+ ** and only if *V is set to a value. ^The sqlite3_vtab_rhs_value(P,J,V)
9754
+ ** inteface returns SQLITE_NOTFOUND if the right-hand side of the J-th
9755
+ ** constraint is not available. ^The sqlite3_vtab_rhs_value() interface
9756
+ ** can return an result code other than SQLITE_OK or SQLITE_NOTFOUND if
9757
+ ** something goes wrong.
9758
+ **
9759
+ ** The sqlite3_vtab_rhs_value() interface is usually only successful if
9760
+ ** the right-hand operand of a constraint is a literal value in the original
9761
+ ** SQL statement. If the right-hand operand is an expression or a reference
9762
+ ** to some other column or a [host parameter], then sqlite3_vtab_rhs_value()
9763
+ ** will probably return [SQLITE_NOTFOUND].
9764
+ **
9765
+ ** ^(Some constraints, such as [SQLITE_INDEX_CONSTRAINT_ISNULL] and
9766
+ ** [SQLITE_INDEX_CONSTRAINT_ISNOTNULL], have no right-hand operand. For such
9767
+ ** constraints, sqlite3_vtab_rhs_value() always returns SQLITE_NOTFOUND.)^
9768
+ **
9769
+ ** ^The [sqlite3_value] object returned in *V is a protected sqlite3_value
9770
+ ** and remains valid for the duration of the xBestIndex method call.
9771
+ ** ^When xBestIndex returns, the sqlite3_value object returned by
9772
+ ** sqlite3_vtab_rhs_value() is automatically deallocated.
9773
+ **
9774
+ ** The "_rhs_" in the name of this routine is an abbreviation for
9775
+ ** "Right-Hand Side".
9776
+ */
9777
+ SQLITE_API int sqlite3_vtab_rhs_value(sqlite3_index_info*, int, sqlite3_value **ppVal);
9778
+
9465
9779
  /*
9466
9780
  ** CAPI3REF: Conflict resolution modes
9467
9781
  ** KEYWORDS: {conflict resolution mode}
@@ -10,12 +10,13 @@
10
10
  </PropertyGroup>
11
11
  <ItemDefinitionGroup>
12
12
  <ClCompile>
13
- <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(MSBuildThisFileDirectory);$(MSBuildThisFileDirectory)..\..\..\deps\common;$(MSBuildThisFileDirectory)..\..\..\deps\common\sqlite3-base64;$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-encode</AdditionalIncludeDirectories>
13
+ <AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);$(MSBuildThisFileDirectory);$(MSBuildThisFileDirectory)..\..\..\deps\common;$(MSBuildThisFileDirectory)..\..\..\deps\common\sqlite3-base64;$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-core</AdditionalIncludeDirectories>
14
14
  <AdditionalOptions>/DSQLITE_THREADSAFE=1 /DSQLITE_DEFAULT_SYNCHRONOUS=3 /DHAVE_USLEEP=1 /DSQLITE_DEFAULT_MEMSTATUS=0 /DSQLITE_OMIT_DECLTYPE /DSQLITE_OMIT_DEPRECATED /DSQLITE_OMIT_PROGRESS_CALLBACK /DSQLITE_OMIT_SHARED_CACHE /DSQLITE_TEMP_STORE=2 /DSQLITE_OMIT_LOAD_EXTENSION /DSQLITE_ENABLE_FTS3 /DSQLITE_ENABLE_FTS3_PARENTHESIS /DSQLITE_ENABLE_FTS4 /DSQLITE_ENABLE_FTS5 /DSQLITE_ENABLE_RTREE /DSQLITE_ENABLE_JSON1 /DSQLITE_DEFAULT_PAGE_SIZE=4096 /DSQLITE_DEFAULT_CACHE_SIZE=-2000 /DSQLITE_OS_WINRT %(AdditionalOptions)</AdditionalOptions>
15
15
  </ClCompile>
16
16
  </ItemDefinitionGroup>
17
17
  <ItemGroup>
18
- <ClInclude Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-encode\cencode.h" />
18
+ <ClInclude Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-core\cencode.h" />
19
+ <ClInclude Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-core\cdecode.h" />
19
20
  <ClInclude Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\sqlite3-base64\sqlite3_base64.h" />
20
21
  <ClInclude Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\sqlite3.h" />
21
22
  <ClInclude Include="$(MSBuildThisFileDirectory)Constants.h" />
@@ -33,7 +34,10 @@
33
34
  <ClCompile Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\sqlite3-base64\sqlite3_base64.c">
34
35
  <CompileAsWinRT>false</CompileAsWinRT>
35
36
  </ClCompile>
36
- <ClCompile Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-encode\cencode.c">
37
+ <ClCompile Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-core\cencode.c">
38
+ <CompileAsWinRT>false</CompileAsWinRT>
39
+ </ClCompile>
40
+ <ClCompile Include="$(MSBuildThisFileDirectory)..\..\..\deps\common\libb64-core\cdecode.c">
37
41
  <CompileAsWinRT>false</CompileAsWinRT>
38
42
  </ClCompile>
39
43
  <ClCompile Include="$(MSBuildThisFileDirectory)pch.cpp">
@@ -41,8 +41,8 @@
41
41
  <MinimumVisualStudioVersion>14.0</MinimumVisualStudioVersion>
42
42
  <AppContainerApplication>true</AppContainerApplication>
43
43
  <ApplicationType>Windows Store</ApplicationType>
44
- <WindowsTargetPlatformVersion>10.0.15063.0</WindowsTargetPlatformVersion>
45
- <WindowsTargetPlatformMinVersion>10.0.10240.0</WindowsTargetPlatformMinVersion>
44
+ <WindowsTargetPlatformVersion>10.0.17763.0</WindowsTargetPlatformVersion>
45
+ <WindowsTargetPlatformMinVersion>10.0.15063.0</WindowsTargetPlatformMinVersion>
46
46
  <ApplicationTypeRevision>10.0</ApplicationTypeRevision>
47
47
  </PropertyGroup>
48
48
 
@@ -1,27 +0,0 @@
1
- libb64: Base64 Encoding C Routine
2
- =================================
3
-
4
- From project: <http://libb64.sourceforge.net/> (latest CVS source from <http://libb64.cvs.sourceforge.net/viewvc/libb64/>)
5
-
6
- LICENSE:
7
- --------
8
-
9
- Public domain
10
-
11
- Authors:
12
- --------
13
-
14
- - Chris Venter ([@gorb314](https://github.com/gorb314))
15
- - Christopher J. Brody ([@brodybits](https://github.com/brodybits))
16
-
17
- Major changes:
18
- --------------
19
-
20
- - Use macro instead of function to encode each value
21
- - Line breaks disabled by default
22
- - Include fixed for iOS build
23
-
24
- Other versions:
25
- ---------------
26
-
27
- - <https://github.com/libb64/libb64>