Documentation Source Text

<title>The Bytecode() And Tables_Used() Table-Valued Functions</title>
<tcl>hd_keywords bcvtab {bytecode virtual table} {tables_used virtual table}</tcl>

<fancy_format>

<h1>Overview</h1>

<p>
Bytecode and tables_used are [virtual tables] built into SQLite that
access information about [prepared statements].
................................................................................
one row for each persistent btree (either a table or an index) accessed
by the prepared statement.

<h1>Usage</h1>

<p>
The bytecode and tables_used tables are only available if SQLite has
been compiled with the -DSQLITE_ENABLE_BYTECODE_VTAB compile-time option.
The [CLI] has been compiled that way, and so you can use the standard
[CLI] as a test platform to experiement.

<p>
Both virtual tables are read-only [eponymous-only virtual tables].  You use them
by mentioning them directly in the FROM clause of a SELECT statement.
They both require a single argument which is the SQL statement to be

<title>The Bytecode() And Tables_Used() Table-Valued Functions</title>
<tcl>hd_keywords bcvtab {bytecode virtual table} {tables_used virtual table} \
  {bytecode and tables_used virtual tables}</tcl>
<fancy_format>

<h1>Overview</h1>

<p>
Bytecode and tables_used are [virtual tables] built into SQLite that
access information about [prepared statements].
................................................................................
one row for each persistent btree (either a table or an index) accessed
by the prepared statement.

<h1>Usage</h1>

<p>
The bytecode and tables_used tables are only available if SQLite has
been compiled with the [-DSQLITE_ENABLE_BYTECODE_VTAB] compile-time option.
The [CLI] has been compiled that way, and so you can use the standard
[CLI] as a test platform to experiement.

<p>
Both virtual tables are read-only [eponymous-only virtual tables].  You use them
by mentioning them directly in the FROM clause of a SELECT statement.
They both require a single argument which is the SQL statement to be

<li> INSERT and UPDATE statements now always apply [column affinity]
     before computing [CHECK constraints].  This bug fix could, in
     theory, cause problems for legacy databases with unorthodox
     CHECK constraints the require the input type for an INSERT
     is different from the declared column type. See ticket
     [https://sqlite.org/src/info/86ba67afafded936|86ba67afafded936]
     for more information.
<li> Added the [sqlite3_create_filename()] and [sqlite3_free_filename()]

     interfaces to better support of [VFS shim] implementations.
<li> Increase the [SQLITE_MAX_VARIABLE_NUMBER|default upper bound]
     on the number of [parameters] from 999 to 32766.
<li> Added code for the [UINT collating sequence] as an optional
     [loadable extension].
<li> Enhancements to the [CLI]:
     <ol type="a">

<li> INSERT and UPDATE statements now always apply [column affinity]
     before computing [CHECK constraints].  This bug fix could, in
     theory, cause problems for legacy databases with unorthodox
     CHECK constraints the require the input type for an INSERT
     is different from the declared column type. See ticket
     [https://sqlite.org/src/info/86ba67afafded936|86ba67afafded936]
     for more information.
<li> Added the [sqlite3_create_filename()], [sqlite3_free_filename()],
     and [sqlite3_database_file_object()]
     interfaces to better support of [VFS shim] implementations.
<li> Increase the [SQLITE_MAX_VARIABLE_NUMBER|default upper bound]
     on the number of [parameters] from 999 to 32766.
<li> Added code for the [UINT collating sequence] as an optional
     [loadable extension].
<li> Enhancements to the [CLI]:
     <ol type="a">

  control.  This can make transactions over twice as fast, while
  simultaneously reducing wear on SSD storage devices.
<p>
  Future versions of SQLite might enable the batch-atomic-write
  capability by default, at which point this compile-time option
  will become superfluous.
}





COMPILE_OPTION {SQLITE_ENABLE_COLUMN_METADATA} {
  When this C-preprocessor macro is defined, SQLite includes some
  additional APIs that provide convenient access to meta-data about
  tables and queries.  The APIs that are enabled by this option are:

  <ul>
................................................................................

COMPILE_OPTION {SQLITE_OMIT_BLOB_LITERAL} {
  When this option is defined, it is not possible to specify a blob in
  an SQL statement using the X'ABCD' syntax.
}

COMPILE_OPTION {SQLITE_OMIT_BTREECOUNT} {
  When this option is defined, an optimization that accelerates counting
  all entries in a table (in other words, an optimization that helps
  "SELECT count(*) FROM table" run faster) is omitted.
}

COMPILE_OPTION {SQLITE_OMIT_BUILTIN_TEST} {
  This compile-time option has been renamed to [SQLITE_UNTESTABLE].
}

COMPILE_OPTION {SQLITE_OMIT_CASE_SENSITIVE_LIKE_PRAGMA} {

  control.  This can make transactions over twice as fast, while
  simultaneously reducing wear on SSD storage devices.
<p>
  Future versions of SQLite might enable the batch-atomic-write
  capability by default, at which point this compile-time option
  will become superfluous.
}

COMPILE_OPTION {SQLITE_ENABLE_BYTECODE_VTAB} {
  This option enables the [bytecode and tables_used virtual tables].
}

COMPILE_OPTION {SQLITE_ENABLE_COLUMN_METADATA} {
  When this C-preprocessor macro is defined, SQLite includes some
  additional APIs that provide convenient access to meta-data about
  tables and queries.  The APIs that are enabled by this option are:

  <ul>
................................................................................

COMPILE_OPTION {SQLITE_OMIT_BLOB_LITERAL} {
  When this option is defined, it is not possible to specify a blob in
  an SQL statement using the X'ABCD' syntax.
}

COMPILE_OPTION {SQLITE_OMIT_BTREECOUNT} {
  This option is no longer used for anything.  It is a no-op.


}

COMPILE_OPTION {SQLITE_OMIT_BUILTIN_TEST} {
  This compile-time option has been renamed to [SQLITE_UNTESTABLE].
}

COMPILE_OPTION {SQLITE_OMIT_CASE_SENSITIVE_LIKE_PRAGMA} {