This doesn't build against current VillageSQL. src/extension.cc still calls villagesql::run_query (lines 151, 188, 221, 257, 355), on_install (637), and make_extension("prometheus_exporter", "0.1.0") (661). None of those exist any more. The 2026-05-24 CI change pointed the build at main with the preview SDK, but the source itself was never migrated.
Replacements:
| Was |
Now |
villagesql::run_query |
preview_sql_query::SqlQueryCapability |
.sys_var(...) |
preview_sys_var::make_capability |
.status_var(...) |
preview_status_var::make_capability |
on_install<>() |
no direct equivalent — a capability's on_populate covers most uses |
make_extension("name", "version") |
make_extension() — name and version come from manifest.json |
preview_thread_worker::ThreadWorkerCapability is optional but would replace the hand-rolled worker thread and its start/stop handling.
The migrated extension needs preview mode enabled. All of the replacements are preview capabilities, and a server refuses to load an extension declaring one unless preview extensions are on:
mysqld --vsql_allow_preview_extensions=ON
It can also be turned on at runtime with SET PERSIST vsql_allow_preview_extensions=ON, which takes effect immediately. SET GLOBAL is rejected — the setting has to survive a restart, because an extension that needs it loads at startup.
If that's not acceptable for how this gets deployed, waiting for these capabilities to graduate is a reasonable call — the migration won't get harder by waiting.
One unrelated thing worth confirming while the code is open: the /metrics endpoint appears to be unauthenticated. (The replica-status collector is already covered by #5.)
Happy to answer questions on any of the capability APIs.
This doesn't build against current VillageSQL.
src/extension.ccstill callsvillagesql::run_query(lines 151, 188, 221, 257, 355),on_install(637), andmake_extension("prometheus_exporter", "0.1.0")(661). None of those exist any more. The 2026-05-24 CI change pointed the build at main with the preview SDK, but the source itself was never migrated.Replacements:
villagesql::run_querypreview_sql_query::SqlQueryCapability.sys_var(...)preview_sys_var::make_capability.status_var(...)preview_status_var::make_capabilityon_install<>()on_populatecovers most usesmake_extension("name", "version")make_extension()— name and version come frommanifest.jsonpreview_thread_worker::ThreadWorkerCapabilityis optional but would replace the hand-rolled worker thread and its start/stop handling.The migrated extension needs preview mode enabled. All of the replacements are preview capabilities, and a server refuses to load an extension declaring one unless preview extensions are on:
It can also be turned on at runtime with
SET PERSIST vsql_allow_preview_extensions=ON, which takes effect immediately.SET GLOBALis rejected — the setting has to survive a restart, because an extension that needs it loads at startup.If that's not acceptable for how this gets deployed, waiting for these capabilities to graduate is a reasonable call — the migration won't get harder by waiting.
One unrelated thing worth confirming while the code is open: the
/metricsendpoint appears to be unauthenticated. (The replica-status collector is already covered by #5.)Happy to answer questions on any of the capability APIs.