Package-level declarations

This method begins a transaction on a virtual table. This method is optional. The xBegin pointer of sqlite3_module may be NULL.

SQLite uses the xBestIndex method of a virtual table module to determine the best way to access the virtual table.

The xClose method closes a cursor previously opened by xOpen. The SQLite core will always call xClose once for each cursor opened using xOpen.

The SQLite core invokes this method in order to find the value for the N-th column of the current row. N is zero-based so the first column is numbered 0. The xColumn method may return its result back to SQLite using one oof the following interfaces:

This method causes a virtual table transaction to commit. This method is optional. The xCommit pointer of sqlite3_module may be NULL.

The xConnect method is very similar to xCreate. It has the same parameters and constructs a new sqlite3_vtab structure just like xCreate. And it must also call sqlite3_declare_vtab() like xCreate. It should also make all of the same sqlite3_vtab_config() calls as xCreate.

The xCreate method is called to create a new instance of a virtual table in response to a CREATE VIRTUAL TABLE statement. If the xCreate method is the same pointer as the xConnect method, then the virtual table is an eponymous virtual table. If the xCreate method is omitted (if it is a NULL pointer) then the virtual table is an eponymous-only virtual table.

Serves both for SqliteVtabCreateCallback and SqliteVtabConnectCallback.

This method releases a connection to a virtual table, just like the xDisconnect method, and it also destroys the underlying table implementation. This method undoes the work of xCreate.

Serves both for SqliteVtabDestroyCallback and SqliteVtabDisconnectCallback.

This method releases a connection to a virtual table. Only the sqlite3_vtab object is destroyed. The virtual table is not destroyed and any backing store associated with the virtual table persists. This method undoes the work of xConnect.

The xEof method must return false (zero) if the specified cursor currently points to a valid row of data, or true (non-zero) otherwise. This method is called by the SQL engine immediately after each xFilter and xNext invocation.

This method begins a search of a virtual table. The first argument is a cursor opened by xOpen. The next two arguments define a particular search index previously chosen by xBestIndex. The specific meanings of idxNum and idxStr are unimportant as long as xFilter and xBestIndex agree on what that meaning is.

This method releases a connection to a virtual table, just like the xDisconnect method, and it also findFunctions the underlying table implementation. This method undoes the work of xCreate.

If the iVersion for an sqlite3_module is 4 or more and the xIntegrity method is not NULL, then the PRAGMA integrity_check and PRAGMA quick_check commands will invoke xIntegrity as part of its processing. If the xIntegrity method writes an error message string into the fifth parameter, then PRAGMA integrity_check will report that error as part of its output. So, in other words, the xIntegrity method allows the PRAGMA integrity_check command to verify the integrity of content stored in a virtual table.

This method provide the virtual table implementation an opportunity to implement nested transactions.

The xNext method advances a virtual table cursor to the next row of a result set initiated by xFilter. If the cursor is already pointing at the last row when this routine is called, then the cursor no longer points to valid data and a subsequent call to the xEof method must return true (non-zero). If the cursor is successfully advanced to another row of content, then subsequent calls to xEof must return false (zero).

The xOpen method creates a new cursor used for accessing (read and/or writing) a virtual table. A successful invocation of this method will allocate the memory for the sqlite3_vtab_cursor (or a subclass), initialize the new object, and make *ppCursor point to the new object.

xRelease callback.

This method notifies the virtual table implementation that the virtual table will be given a new name. If this method returns SQLITE_OK then SQLite renames the table. If this method returns an error code then the renaming is prevented.

This method causes a virtual table transaction to rollback. This method is optional. The xRollback pointer of sqlite3_module may be NULL.

xRollbackTo callback.

A successful invocation of this method will cause *pRowid to be filled with the rowid of row that the virtual table cursor pCur is currently pointing at. This method returns SQLITE_OK on success. It returns an appropriate error code on failure.

xSavepoint callback.

Some virtual table implementations (ex: FTS3, FTS5, and RTREE) make use of real (non-virtual) database tables to store content. For example, when content is inserted into the FTS3 virtual table, the data is ultimately stored in real tables named "%_content", "%_segdir", "%_segments", "%_stat", and "%_docsize" where "%" is the name of the original virtual table. These auxiliary real tables that store content for a virtual table are called "shadow tables". See (1), (2), and (3) for additional information.

This method signals the start of a two-phase commit on a virtual table. This method is optional. The xSync pointer of sqlite3_module may be NULL.

Serves both for SqliteVtabBeginCallback, SqliteVtabSyncCallback, SqliteVtabCommitCallback and SqliteVtabRollbackToCallback.

All changes to a virtual table are made using the xUpdate method. This one method can be used to insert, delete, or update.