VillageSQL 固有の機能
VEF が提供するもののうちいくつかは、以下の表に比較対象がありません。MySQL の構造が異なるため、あるいは VillageSQL の拡張機能作成者が PostgreSQL では自身の拡張機能に提供されていないものを必要としたためです。- Keyring アクセス —
vsql::preview::keyringにより、拡張機能はサーバーの keyring からシークレットを読み取ることができます。 - InnoDB ページストレージ —
vsql::preview::storageにより、拡張機能は InnoDB セグメントを作成し、バッファプールを通じてそのページを読み書きできます。redo ログにも記録されます。 - 代替プロトコルハンドラ — #299 により、拡張機能は MySQL ワイヤプロトコル以外の方法でクライアントに応答できるようになります。
表の読み方
利用可能 と記されていないすべての行は、その行または表の下の注記で、その作業が追跡および議論されている GitHub Issue にリンクしています。
プレビュー機能を通じて 利用可能 と記されているものには、
vsql_allow_preview_extensions = ON が必要です — プレビュー機能を参照してください。vsql::preview::auth と vsql::preview::statement_event は、開発 ABI（-DVSQL_USE_DEV_ABI=ON）でビルドされた拡張機能からのみ利用できます。
C++ と Rust
VillageSQL の拡張機能は C++ または Rust のどちらでも作成できます。VEF はサーバー側の機能であり、各 SDK はその上のバインディングです。Rust バインディングはより新しいため、いくつかの機能は現時点では C++ からのみ利用できます。プラガブルインターフェース
最もよく知られた PostgreSQL の拡張機能が構築されている基盤は、この後に続くフックではなく、これらのインターフェースです。これらはフレームワークの中で VEF が最も完全にカバーしている部分でもあるため、ここから始めてください。on_init() および on_deinit() は、拡張機能が宣言した機能が有効な状態で実行されます。on_init() はサーバーがそれらを設定した後、on_deinit() はサーバーがそれらを解除する前に実行されるため、フックは登録済みのシステム変数を読み取ることができます。CPU 固有の関数ポインタの選択など、ローカルなセットアップにも適しています。
vsql::preview::sql_query には、SPI を中心に構築されるすべての拡張機能に影響する 3 つの制限があります。文はバインドパラメータを取らないため、値は手動でエスケープする必要があります（#627）。拡張機能は同時実行のセッションではなく、単一のセッションを取得します（#626）。そして、VDF の内部からは呼び出せません（#597）。
フック変数
フックとは、サーバーが文の実行中に拡張機能へ制御を渡し、サーバーがこれから行おうとしていることを拡張機能が読み取ったり変更したりできるようにする地点です。PostgreSQL はグローバルな関数ポインタとして固定のフックセットを宣言しています。以下の表はそのすべてを、各フックが発火するクエリ処理の段階ごとに分類して示しています。解析と DDL
プランナ
エグゼキュータ
オペレータ単位の詳細を必要とする PostgreSQL の拡張機能は、ノードレベルで
ExecutorRun_hook をラップすることでこれを取得します。VEF ではこれは別の作業であり、#340 で追跡されています。
EXPLAIN
認証とセキュリティ
PostgreSQL の拡張機能は
ClientAuthentication_hook を 2 つの異なる目的で使用しており、VEF はそのうちの 1 つをカバーしています。拡張機能は vsql::preview::auth 機能を通じて独自の認証方式を実装できます。vsql-oauth2 はこれを基盤としています。一方、自身が処理していない認証の結果を監視することはまだできません。これは PostgreSQL の auth_delay やログイン失敗のトラッカーが動作する方法です。その部分は #464 です。
PostgreSQL は、フックではなく pg_ident.conf を通じて外部 ID をデータベースアカウントにマッピングします。VEF は同じ vsql::preview::auth 機能でこれをカバーしています。set_active_roles() により、認証プラグインは外部 ID を解決した後にセッション用のロールをステージングでき、roles_mode() は、ログインのたびに再問い合わせされるコールバックを登録します。このコールバックは、サーバーがステージングされたロールを有効化するだけか、付与も行うか、アカウントの付与をそれに合わせて同期するか（運用者が固定した DEFAULT ROLE は同期後も保持されます）を決定します。どちらも villagesql/sdk/include/villagesql/preview/auth.h で宣言されています。