> ## Documentation Index
> Fetch the complete documentation index at: https://villagesql.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# PostgreSQLと比較したVEFのカバレッジ
> このページは、VillageSQL 拡張フレームワークと PostgreSQL の拡張フレームワークを比較し、VEF が現在どのインターフェースとフックをサポートしているか、そして残りの作業がどこで追跡されているかを示します。
VillageSQL 拡張フレームワーク（VEF）は、定義された方法でデータベースの内部動作へのアクセスを拡張機能に提供します。PostgreSQL はオープンソースデータベースの中で最も成熟した拡張フレームワークを持っているため、このページでは PostgreSQL を参照点として使用し、VEF の現在および計画中の機能の全体像を示します。
このページは完成した状態ではなく、スナップショットとしてお読みください。VEF はリリースごとに変化します。PostgreSQL のフック機能に正確に一致させることが目標ではありません。MySQL と PostgreSQL は異なるデータベースであり、それぞれのユーザーのニーズも多くの場合異なります。
VillageSQL 固有の機能
VEF が提供するもののうちいくつかは、以下の表に比較対象がありません。MySQL の構造が異なるため、あるいは VillageSQL の拡張機能作成者が PostgreSQL では自身の拡張機能に提供されていないものを必要としたためです。
* **Keyring アクセス** — `vsql::preview::keyring` により、拡張機能はサーバーの keyring からシークレットを読み取ることができます。
* **拡張機能専用のファイルストレージ** — `vsql::preview::storage` は、拡張機能にサーバー管理下のディスク領域を提供します。PostgreSQL の拡張機能は、サーバー側 API なしで自身のファイルを管理します。
* **代替プロトコルハンドラ** —
[#299](https://github.com/villagesql/villagesql-server/issues/299) により、拡張機能は MySQL ワイヤプロトコル以外の方法でクライアントに応答できるようになります。
さらに 2 つの機能は、MySQL の構造に由来します。バイナリログの書き込みおよびフラッシュの監視（[#297](https://github.com/villagesql/villagesql-server/issues/297)）とレプリケーションチャネルの監視（[#341](https://github.com/villagesql/villagesql-server/issues/341)）は、どちらも MySQL のバイナリログとマルチソースレプリケーションチャネルを読み取ります。PostgreSQL は WAL の論理デコードとサブスクリプション機構によって同等の領域をカバーしており、これは同様の目的に対する異なる設計です。
表の読み方
| 状態 | 意味 |
| -------- | ------------------------------------------------------- |
| **利用可能** | 現在、拡張機能でこれを行うことができます。その行には、これを提供する機能または SDK 関数が示されています。 |
| **部分的** | 一部が現在動作します。その行、または表の下の注記に、何が不足しているかが示されています。 |
| **進行中** | 作業の一部が完了しています。リンクされた Issue が残りを担っています。 |
| **計画中** | まだ利用できません。リンクされた Issue が作業を追跡しています。 |
**利用可能** と記されていないすべての行は、その作業が追跡および議論されている GitHub Issue にリンクしています。
プレビュー機能を通じて **利用可能** と記されているものには、`vsql_allow_preview_extensions = ON` が必要です — [プレビュー機能](/docs/ja/mysql-9.7/stable/preview-capabilities)を参照してください。
C++ と Rust
VillageSQL の拡張機能は C++ または Rust のどちらでも作成できます。VEF はサーバー側の機能であり、各 SDK はその上のバインディングです。Rust バインディングはより新しいため、いくつかの機能は現時点では C++ からのみ利用できます。
| 機能 | C++ SDK | Rust SDK |
| ------------------ | ------- | -------------------------------------------------------------------------- |
| スカラー関数（VDF） | 対応 | 対応 |
| カスタム型 | 対応 | 対応 |
| システム変数とステータス変数 | 対応 | 対応 |
| バックグラウンドワーカー | 対応 | 対応 |
| Keyring アクセス | 対応 | 対応 |
| 集約関数 | 対応 | 対応 |
| ロードおよびアンロードのコールバック | 対応 | 未対応 — [rust-sdk#13](https://github.com/villagesql/vsql-rust-sdk/issues/13) |
| 拡張機能からの SQL 実行 | 対応 | 未対応 — [rust-sdk#37](https://github.com/villagesql/vsql-rust-sdk/issues/37) |
| ステートメント完了イベント | 対応 | 未対応 — [rust-sdk#37](https://github.com/villagesql/vsql-rust-sdk/issues/37) |
| 認証方式 | 対応 | 未対応 — [rust-sdk#37](https://github.com/villagesql/vsql-rust-sdk/issues/37) |
| 拡張機能専用ストレージ | 対応 | 未対応 — [rust-sdk#37](https://github.com/villagesql/vsql-rust-sdk/issues/37) |
プラガブルインターフェース
最もよく知られた PostgreSQL の拡張機能が構築されている基盤は、この後に続くフックではなく、これらのインターフェースです。これらはフレームワークの中で VEF が最も完全にカバーしている部分でもあるため、ここから始めてください。
| PostgreSQL インターフェース | 動作 | VillageSQL |
| --------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `_PG_init`、`_PG_fini` | モジュールのロード時にセットアップを実行し、アンロード時に終了処理を実行する | **利用可能** — 拡張機能ビルダーの `on_init()` および `on_deinit()` |
| カスタムデータ型と演算子 | 独自のストレージと比較動作を持つ新しい基本型を登録する | **利用可能** — [C++でのカスタム型](/docs/ja/mysql-9.7/stable/custom-types)を参照 |
| 集約関数 | ユーザー定義の集約を登録する | **利用可能** — `make_aggregate_func`、[C++ 開発](/docs/ja/mysql-9.7/stable/development)を参照 |
| カスタム設定変数 | 運用者が実行時に変更できる設定と、読み取れるカウンターを定義する | **利用可能** — 設定には `vsql::sys_var`、カウンターには `vsql::status_var` |
| バックグラウンドワーカー | データベースアクセスを持つ長寿命プロセスをサーバー内で実行する | **利用可能** — `vsql::preview::thread_worker` |
| SPI（サーバー内部からの SQL 実行） | 拡張機能のコードから SQL を実行する | **部分的** — `vsql::preview::sql_query`、以下に示す制限あり |
| 集合を返す関数 | 関数から結果セットを返す | 計画中 — [#549](https://github.com/villagesql/villagesql-server/issues/549) |
| C で書かれたプロシージャ | 操作をスカラー関数ではなく `CALL` として公開する | 計画中 — [#596](https://github.com/villagesql/villagesql-server/issues/596) |
| インデックスアクセスメソッド | 構築、メンテナンス、検索を含むインデックス型全体を登録する | 進行中 — [#264](https://github.com/villagesql/villagesql-server/issues/264)、[#265](https://github.com/villagesql/villagesql-server/issues/265)、[#266](https://github.com/villagesql/villagesql-server/issues/266)、[#268](https://github.com/villagesql/villagesql-server/issues/268) |
| カスタムスキャンプロバイダ | 拡張機能が定義したノードをエグゼキュータに追加する | 計画中 — [#276](https://github.com/villagesql/villagesql-server/issues/276) |
| テーブルアクセスメソッド | 行のストレージ、可視性、vacuum の動作を置き換える | 計画中 — [#290](https://github.com/villagesql/villagesql-server/issues/290)、[#291](https://github.com/villagesql/villagesql-server/issues/291)、[#292](https://github.com/villagesql/villagesql-server/issues/292) |
| 外部データラッパー | 述語プッシュダウンと書き込みを備えて、外部システムをテーブルとして公開する | 計画中 — [#277](https://github.com/villagesql/villagesql-server/issues/277)、[#278](https://github.com/villagesql/villagesql-server/issues/278)、[#279](https://github.com/villagesql/villagesql-server/issues/279)、[#280](https://github.com/villagesql/villagesql-server/issues/280) |
| 論理デコードの出力プラグイン | 行変更のストリームを消費する | 計画中 — [#283](https://github.com/villagesql/villagesql-server/issues/283)、[#284](https://github.com/villagesql/villagesql-server/issues/284)、[#285](https://github.com/villagesql/villagesql-server/issues/285) |
| 拡張機能の状態を示すシステムビュー | 拡張機能の状態をクエリ可能なテーブルとして公開する | 計画中 — [#271](https://github.com/villagesql/villagesql-server/issues/271) |
| 手続き型言語 | ストアドルーチン用の言語ランタイムを追加する | 計画中 — [#342](https://github.com/villagesql/villagesql-server/issues/342) |
`on_init()` および `on_deinit()` は、`_PG_init` とは異なり、サーバーへのアクセスなしに拡張機能の内部で実行されます。CPU 固有の関数ポインタの選択など、ローカルなセットアップに適しています。サーバーとやり取りする必要があるセットアップは、機能の populate ステップで行ってください。
`vsql::preview::sql_query` には、SPI を中心に構築されるすべての拡張機能に影響する 3 つの制限があります。文はバインドパラメータを取らないため、値は手動でエスケープする必要があります（[#627](https://github.com/villagesql/villagesql-server/issues/627)）。拡張機能は同時実行のセッションではなく、単一のセッションを取得します（[#626](https://github.com/villagesql/villagesql-server/issues/626)）。そして、VDF の内部からは呼び出せません（[#597](https://github.com/villagesql/villagesql-server/issues/597)）。
フック変数
フックとは、サーバーが文の実行中に拡張機能へ制御を渡し、サーバーがこれから行おうとしていることを拡張機能が読み取ったり変更したりできるようにする地点です。PostgreSQL はグローバルな関数ポインタとして固定のフックセットを宣言しています。以下の表はそのすべてを、各フックが発火するクエリ処理の段階ごとに分類して示しています。
解析と DDL
| PostgreSQL フック | 動作 | VillageSQL |
| --------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------ |
| `post_parse_analyze_hook` | 解析後の文を検査または書き換える | 計画中 — [#701](https://github.com/villagesql/villagesql-server/issues/701) |
| `ProcessUtility_hook` | DDL やその他のユーティリティ文の実行前に、これらを傍受、ブロック、またはリダイレクトする | 計画中 — [#272](https://github.com/villagesql/villagesql-server/issues/272) |
| `object_access_hook`、`object_access_hook_str` | カタログオブジェクトが作成、変更、削除、またはアクセスされたときに通知を受け取る | 計画中 — [#270](https://github.com/villagesql/villagesql-server/issues/270) |
プランナ
| PostgreSQL フック | 動作 | VillageSQL |
| ------------------------------------------------ | ----------------------------------- | ------------------------------------------------------------------------ |
| `planner_hook` | 文に対するプランナをラップまたは置き換える | 計画中 — [#275](https://github.com/villagesql/villagesql-server/issues/275) |
| `set_rel_pathlist_hook` | 1 つのテーブルに対する候補スキャンパスを追加または削除する | 計画中 — [#275](https://github.com/villagesql/villagesql-server/issues/275) |
| `set_join_pathlist_hook` | 候補となる結合パスを追加または削除する | 計画中 — [#275](https://github.com/villagesql/villagesql-server/issues/275) |
| `join_search_hook` | 結合順序の探索自体を置き換える | 計画中 — [#275](https://github.com/villagesql/villagesql-server/issues/275) |
| `create_upper_paths_hook` | グループ化や並べ替えなど、スキャン後の段階のパスを追加する | 計画中 — [#275](https://github.com/villagesql/villagesql-server/issues/275) |
| `get_relation_info_hook` | プランナが参照するリレーションとインデックスのメタデータを調整する | 計画中 — [#268](https://github.com/villagesql/villagesql-server/issues/268) |
| `get_relation_stats_hook`、`get_index_stats_hook` | カタログの統計情報の代わりに、列またはインデックスの統計情報を提供する | 計画中 — [#274](https://github.com/villagesql/villagesql-server/issues/274) |
| `get_attavgwidth_hook` | コスト見積もり用に列の平均幅を提供する | 計画中 — [#274](https://github.com/villagesql/villagesql-server/issues/274) |
エグゼキュータ
| PostgreSQL フック | 動作 | VillageSQL |
| ------------------------- | ------------------------------ | ------------------------------------------------------------------------ |
| `ExecutorStart_hook` | クエリの実行開始前に実行する | 計画中 — [#702](https://github.com/villagesql/villagesql-server/issues/702) |
| `ExecutorRun_hook` | マスキング、変換、行単位の集計のために、行の生成をラップする | 計画中 — [#289](https://github.com/villagesql/villagesql-server/issues/289) |
| `ExecutorFinish_hook` | 最後の行の後、終了処理の前に実行する | 計画中 — [#287](https://github.com/villagesql/villagesql-server/issues/287) |
| `ExecutorEnd_hook` | 完了した文とその実行統計を監視する | **利用可能** — `vsql::preview::statement_event`、post-execute フェーズ |
| `ExecutorCheckPerms_hook` | 文が必要とするテーブルおよび列の権限を承認または拒否する | 計画中 — [#314](https://github.com/villagesql/villagesql-server/issues/314) |
オペレータ単位の詳細を必要とする PostgreSQL の拡張機能は、ノードレベルで `ExecutorRun_hook` をラップすることでこれを取得します。VEF ではこれは別の作業であり、[#340](https://github.com/villagesql/villagesql-server/issues/340) で追跡されています。
EXPLAIN
| PostgreSQL フック | 動作 | VillageSQL |
| ------------------------------- | ------------------------------------ | ------------------------------------------------------------------------ |
| `ExplainOneQuery_hook` | 文に対する `EXPLAIN` 処理を置き換えるか拡張する | 計画中 — [#317](https://github.com/villagesql/villagesql-server/issues/317) |
| `explain_per_plan_hook` | `EXPLAIN` 対象のプランごとに 1 回、拡張機能の出力を追加する | 計画中 — [#317](https://github.com/villagesql/villagesql-server/issues/317) |
| `explain_per_node_hook` | 各プランノードに対して拡張機能の出力を追加する | 計画中 — [#317](https://github.com/villagesql/villagesql-server/issues/317) |
| `explain_get_index_name_hook` | 出力に表示されるインデックス名を上書きする | 計画中 — [#317](https://github.com/villagesql/villagesql-server/issues/317) |
| `explain_validate_options_hook` | 拡張機能が定義した `EXPLAIN` オプションを受け付ける | 計画中 — [#317](https://github.com/villagesql/villagesql-server/issues/317) |
認証とセキュリティ
| PostgreSQL フック | 動作 | VillageSQL |
| ---------------------------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------ |
| `ClientAuthentication_hook` | 認証に参加し、その結果を監視する | **部分的** — 以下を参照 |
| `check_password_hook` | パスワード設定時にパスワードポリシーを強制する | 計画中 — [#456](https://github.com/villagesql/villagesql-server/issues/456) |
| `ldap_password_hook` | `ldap` 認証方式が使用する LDAP バインドを置き換える | **利用可能** — `vsql::preview::auth` で方式自体を実装する |
| `openssl_tls_init_hook` | 起動時にサーバーの TLS コンテキストを調整する | 計画中 — [#458](https://github.com/villagesql/villagesql-server/issues/458) |
| `row_security_policy_hook_permissive`、`row_security_policy_hook_restrictive` | セッションに基づいて行フィルタの述語をクエリに追加する | 計画中 — [#315](https://github.com/villagesql/villagesql-server/issues/315) |
PostgreSQL の拡張機能は `ClientAuthentication_hook` を 2 つの異なる目的で使用しており、VEF はそのうちの 1 つをカバーしています。拡張機能は `vsql::preview::auth` 機能を通じて独自の認証方式を実装できます。`vsql-oauth2` はこれを基盤としています。一方、自身が処理していない認証の結果を監視することはまだできません。これは PostgreSQL の `auth_delay` やログイン失敗のトラッカーが動作する方法です。その部分は [#464](https://github.com/villagesql/villagesql-server/issues/464) です。
PostgreSQL は、フックではなく `pg_ident.conf` を通じて外部 ID をデータベースアカウントにマッピングします。VEF は同じ `vsql::preview::auth` 機能でこれをカバーしています。`set_active_roles()` により、認証プラグインは外部 ID を解決した後にセッションへロールを割り当てることができ、`auto_grant_roles()` はトークンのクレームに基づいてロールを自動的に付与するコールバックを登録します。どちらも `villagesql/sdk/include/villagesql/preview/auth.h` で宣言されています。
ロギング
| PostgreSQL フック | 動作 | VillageSQL |
| --------------- | ---------------------------------------- | ------------------------------------------------------------------------ |
| `emit_log_hook` | 各ログメッセージが書き込まれる前に確認し、フィルタリングまたは再ルーティングする | 計画中 — [#316](https://github.com/villagesql/villagesql-server/issues/316) |
起動と共有メモリ
| PostgreSQL フック | 動作 | VillageSQL |
| -------------------- | ------------------------ | ------------------------------------------------------------------------ |
| `shmem_request_hook` | 起動中に共有メモリを要求する | 計画中 — [#282](https://github.com/villagesql/villagesql-server/issues/282) |
| `shmem_startup_hook` | 共有メモリが存在するようになった時点で初期化する | 計画中 — [#282](https://github.com/villagesql/villagesql-server/issues/282) |
ファンクションマネージャ
| PostgreSQL フック | 動作 | VillageSQL |
| ----------------------------- | -------------------------------------- | ------------------------------------------------------------------------ |
| `fmgr_hook`、`needs_fmgr_hook` | 監査やサンドボックス化のために、すべての関数呼び出しの前後でコードを実行する | 計画中 — [#287](https://github.com/villagesql/villagesql-server/issues/287) |
必要なものをお知らせください
私たちは、拡張機能の作成者からの要望に基づいてこの作業の優先順位を決定しています。上記のいずれかが、あなたが構築したい拡張機能の妨げになっている場合は、その Issue に 👍 を付け、ユースケースをコメントで説明してください。