Skip to main content
Query extension metadata and server state using the standard SQL interfaces below.

System Views

INFORMATION_SCHEMA.EXTENSIONS

Lists all currently installed VillageSQL extensions.
INSTALL EXTENSION and UNINSTALL EXTENSION are VillageSQL SQL extensions. They are not part of standard MySQL 9.7 syntax.
Known columns: Example:
Illustrative output (actual version strings depend on installed extensions):
EXTENSION_NAME values are lowercase, matching the name passed to make_extension(). The view reflects the current installed state. The four PENDING_* columns track a scheduled ALTER EXTENSION ... AT RESTART version change. See Managing Extensions for the workflow.

INFORMATION_SCHEMA.COLUMNS (Custom Types)

Columns using custom extension types are visible through the standard INFORMATION_SCHEMA.COLUMNS view. Custom types appear as extension_name.type_name in the DATA_TYPE and COLUMN_TYPE columns (e.g., vsql_complex.COMPLEX). Example:
Sample Output:

INFORMATION_SCHEMA.EXTENSION_REGISTRATION

Exposes the in-memory VEF registration struct for each loaded extension as a JSON document. Use it to verify that the server parsed your extension’s functions, types, and system variables correctly after INSTALL EXTENSION.

Common Queries

Find Extension Dependencies

Find which columns use a specific extension’s types before uninstalling:

List All Extensions and Their Custom Type Columns

Find Tables Using Extension Types


System Variables

veb_dir

Read-only at runtime. Path to the directory where the server looks for .veb extension bundle files. Set in my.cnf under [mysqld]; cannot be changed without a server restart.
Scope: Global, read-only at runtime. Configure in my.cnf:
Only a single directory is supported. See Managing Extensions for placement and troubleshooting.

villagesql_server_version

Read-only global variable. Returns the VillageSQL version string compiled into the server binary. The format is {codebase}_{major}.{minor}.{patch}[-prerelease], where codebase names the upstream fork this build derives from (here, mysql-9.7). This is distinct from villagesql_schema_version, which reports the version stamped on the internal metadata catalog in the same {codebase}_{version} format.
Scope: Global, read-only. Cannot be set at runtime.

villagesql_schema_version

Read-only global variable. Returns the version stamped on the internal metadata catalog, in the same {codebase}_{version} format as villagesql_server_version. An empty string means the VillageSQL schema has not been initialized in this data directory.
Scope: Global, read-only. Cannot be set at runtime.

villagesql_vef_server_protocol

Read-only global variable. Returns the highest VEF protocol version supported by this server build. When an extension is installed, the server and the extension settle on the highest protocol version both support. An extension built against an obsolete unstable protocol version cannot be installed — INSTALL EXTENSION fails with Failed to load VEF extension.
Protocol V4 adds support for variable-length custom types and lets a function declare the maximum length of its string results. It is under active development behind the opt-in dev ABI and may change before it stabilises. If you are developing extensions, see Type Operations and Creating Extensions in C++ for what each protocol version enables. The value reflects the compile-time constant vef_server_protocol_version and cannot be changed at runtime.

villagesql_build_info

Read-only global variable. Returns a JSON object with metadata about how this server binary was built: the source commit, work-tree state, and build environment.
Scope: Global, read-only. Cannot be set at runtime. A build from a modified work tree shows non-zero counts in files_added, files_deleted, or files_modified, and is_dirty is then true. A release build — one whose version carries no pre-release suffix — forces those three counts to zero and leaves build_timestamp and build_host empty so that identical sources produce an identical binary, which is why is_dirty is always false on a release.

vsql_allow_preview_extensions

Controls whether the server accepts extensions that require a preview capability. While it is OFF, installing one fails:
Turn it on with SET PERSIST:
Use SET PERSIST, not SET GLOBAL. Preview extensions are loaded at server startup, so the value has to survive a restart, and only SET PERSIST writes it to mysqld-auto.cnf; SET GLOBAL is rejected for that reason. Before mysqld-auto.cnf exists — on a server being started for the first time — pass --vsql_allow_preview_extensions=ON on the mysqld command line instead. Turning it back off is rejected while any extension using a preview capability is still installed, because those extensions require the setting to be ON when the server starts. Uninstall them first. See Preview Capabilities for the list of preview capabilities and what an extension does with them.

Next Steps

Managing Extensions

Monitor and troubleshoot extensions

Install Extensions

Add new extensions

Extension Architecture

Understand the internals

Available Extensions

Browse extension catalog