VillageSQL

Announcing VillageSQL Server 0.0.5

Adam Levin

Adam Levin

— 4 min read
Share
Purple background with the number 0.0.5 printed on

VillageSQL Server 0.0.5 is now available (and marked as the stable release for installs). This release is focused on the extension lifecycle: upgrading an extension in place, pinning the exact version you install, and seeing what's running. The extension framework also adds variable-length custom types and statement-event hooks. VillageSQL Server 0.0.5 tracks Oracle MySQL 8.4.10 and includes all upstream fixes from that branch.

Upgrading extensions

One of the most critical pieces of managing an extension is being able to upgrade it. ALTER EXTENSION introduces the syntax for upgrade, and with it the safety checks that run before an upgrade is allowed to touch your data.

ALTER EXTENSION my_ext VERSION '2.0.0' AT RESTART;

Asking for the version you already have is a no-op with a note. Asking for a different version triggers a set of pre-checks against the target package: it refuses an upgrade that would drop a type still used by your columns, one whose persisted length doesn't match what's already on disk, or one whose VEB is missing.

AT RESTART is required, and right now it's the only mode. The upgrade doesn't apply live: once the pre-checks pass, the server records the version you asked for and applies it the next time it restarts. You stage the change now, and it lands on your next planned restart.

We consider this a v1. In 0.0.5 the syntax and the pre-check layer land, applied on restart. If you have a different upgrade workflow you want this to support, we'd like to hear about it on Discord or via Issues.

Pinning the extension version

INSTALL EXTENSION now takes a VERSION clause. Name a version that doesn't match the package on disk and the install is refused before anything happens:

INSTALL EXTENSION vsql_simple VERSION '9.9.9';
-- ERROR 3219 (HY000): Cannot install extension 'vsql_simple':
-- manifest version is '0.0.1' but VERSION '9.9.9' was specified

If you load several builds of the same extension VEB side by side, the version you name selects which one loads. The same assertion guards UNINSTALL, so a teardown script can't remove a version it wasn't written for. A deployment can now state the version it expects and fail loudly when reality disagrees, instead of silently running against whatever VEB happened to be on disk.

Seeing what's installed

INFORMATION_SCHEMA.EXTENSIONS answers "what's running" without shelling into the box to inspect files: it lists every installed extension and its version, and (new this release) surfaces any pending upgrade. When you stage an ALTER EXTENSION ... AT RESTART, the PENDING_VERSION, PENDING_REQUESTED_AT, PENDING_LAST_ERROR, and PENDING_LAST_ERROR_AT columns show what's queued and whether the last apply attempt failed, so a dashboard can watch a staged upgrade the same way it watches everything else in the database. INFORMATION_SCHEMA.EXTENSION_REGISTRATION reports the protocol the server and each extension negotiated. You can query both from any client.

More Capabilities for Extension Authors

Release 0.0.5 lands new capabilities for building extensions:

The first is variable-length custom types. Until now a custom type had a fixed stored size. Now, that size can vary from one row to the next, so an extension can define a type whose values differ in length, with the stored bytes round-tripping through SHOW CREATE TABLE and out-of-range values rejected at insert time. This makes variable-size types like arrays or packed structures possible, where each value takes only the space it needs instead of a fixed size set when the column is created. A NOT NULL column of one of these types is backed by a proper default value rather than an empty one.

The second is statement-event hooks. An extension can subscribe to statement-completion events, which is the foundation for per-query telemetry or a slow-query log shipped as an extension. Statements that carry secrets (CREATE USER ... IDENTIFIED BY, ALTER USER ... IDENTIFIED BY, SET PASSWORD) reach the hook with those values redacted. This capability is currently in preview.

There's also a smaller type-system refinement: a parameterized custom type can supply default parameters a user leaves off, so a column declared without them still persists an explicit, canonical definition that survives SHOW CREATE TABLE and reload unchanged.

Fix for extensions that return text

A STRING-returning function now grows its result buffer instead of cutting the value off. Earlier builds capped output at a small fixed width: 255 bytes on a plain SELECT, or the argument width on grouped and materialized queries like GROUP BY and CREATE TABLE ... SELECT, so a function returning a longer value, or an aggregate building up a long string, came back truncated. The server now reads the full size the function reports, grows the buffer to fit, and re-invokes the function so the whole value comes back. Only a result larger than max_allowed_packet returns NULL with a warning which is the same way MySQL's own string functions behave. Text results also carry a utf8mb4 charset now, so clients show them as text instead of hex.

New extensions

The extension catalog grew this cycle:

  • vsql-trgm: trigram-based text-similarity search, a port of PostgreSQL's pg_trgm.
  • vsql-fuzzystrmatch: phonetic and edit-distance string matching, including Soundex, Levenshtein, and Metaphone, following PostgreSQL's fuzzystrmatch.
  • vsql-nanoid (community by intojhanurag): short, URL-safe random identifiers, a Nano ID port.
  • vsql-luhn (community by intojhanurag): Luhn checksum validation and check-digit generation, the algorithm behind card and account number checks.

What's ahead

Looking ahead, we're expanding the query-hook surface beyond statement-completion events: query-lifecycle hooks, DDL-event subscription, per-consumer stream filtering, and shared-memory access for extensions are all in progress. Custom indexes and vector search are underway. We're also "productionizing" the extension framework, adding MySQL 9.7 as a supported version, and working to include Percona's open-source improvements in the same server as the VEF improvements.

Special thanks

VillageSQL would like to thank the external contributors pyshx, ronaldbradford, renecannao, and intojhanurag for their contributions and feedback in this release.

There is more in this release. Check the Release Notes for additional details. Please let us know what extensions you're building and what we should focus on building next. Our entire roadmap is published on GitHub. If you want to get involved in the community, we appreciate code contributions. You can discuss the roadmap with us on GitHub or on Discord.

Read more