schema-exploration

PostgreSQL データベースを調査する

ユーザーの質問から始めてください。明示的に求められていない限り、データベース全体の監査は行わないでください。すでに利用可能なデータベース接続を使用してください。接続がない場合は、アクセスを依頼するか、提供されたスキーマファイルを使って作業してください。ユーザーが許可したデータベースとスキーマの範囲内にとどめてください。カタログのメタデータから機密性の高い名前やソースコードが明らかになることがあります。不要にエクスポートしないでください。

ワークフロー

1. 現在のデータベース、サーバーのバージョン、ロール、対象範囲を確認します。小規模なインベントリには概要を使用してください。関連するスキーマを選び、アプリケーションがpublicにあると決めつけないでください。
2. 有望なオブジェクトを選び、該当する詳細リファレンスだけを参照してください：テーブル、パーティショニング／継承、外部テーブル、ビュー、ルーチン、トリガー、セキュリティ／RLS、または拡張機能。質問への回答に必要な場合に限り、相互参照先も確認してください。
3. コメント、定義、キー、既知の依存関係を使って意味を裏付けます。名前は手がかりであり、業務上の意味の証明ではありません。データから導出した値が役立つ場合は、対象の列とアクセス方法について承認を得た後に限り、データから導出した値を使用してください。意味が曖昧なままであれば、ユーザーに確認してください。
4. ユーザーが SQL を求めている場合は、クエリの作成に従ってください。結合キーと粒度を確定してから、許可されている範囲で、精査済みの読み取り専用クエリをプレーンなEXPLAINで検証します。有効な実行計画が得られても、業務上の意味が証明されたと考えてはいけません。
5. 回答に必要な情報が得られたら、調査を終了します。具体的なスキーマ修飾済みオブジェクトと根拠を示し、観察結果と推論を区別して、制約（権限、古い統計情報、欠落した依存関係、不明なアプリケーションロジック）を明記してください。

調査結果の例

あくまで例です。対象データベースで確認できた事実を報告してください。

• 観察結果： sales.ordersにはorder_idを主キーとする制約があり、account_idからsales.accounts.account_idへの外部キーがあります。
• 推論： sales.ordersは注文ごとに1行を記録している可能性が高いです。キーはこれを裏付けますが、業務上の「注文」が何を指すかまでは示しません。
• 未解決： キャンセルされた注文がこのテーブルに残るかどうかは、カタログからは分かりません。残ると決めつける前に、アプリケーションの担当者に確認してください。

安全性と実行

• 構造を調べるカタログクエリを優先してください。pg_statsはデータから導出されるため、こちらも承認が必要です。許可なくスキーマ、データ、ロール、セッション全体の設定を変更しないでください。見つかった関数やプロシージャを呼び出したり、マテリアライズドビューを更新したり、内容が不明なクエリに対してEXPLAIN ANALYZEを実行したりしないでください。STABLEまたはIMMUTABLEとマークされた関数も、安全性を保証するものではありません。
• クライアントがトランザクションに対応している場合は、調査に読み取り専用トランザクションを使用し、妥当なステートメントタイムアウトを設定してください。メタデータクエリを実行できるからといって、全テーブルの件数を数えたり、制限のないスキャンを行ったりしてよいわけではありません。データのサンプリングは事前に確認し、必要な場合に限り、明示的な上限を設け、テーブルのサイズとアクセス制御を十分に把握したうえで実施してください。
• すべてのリファレンスクエリは、プレーンな PostgreSQL SQL です。$1、$2などは、クライアントの API を使って値としてバインドしてください。psqlユーザーは、任意のpsql アダプターを利用できます。信頼できないオブジェクト名を、生の SQL として埋め込まないでください。データクエリでは、プレースホルダーで SQL 識別子を置き換えることはできません。
• クエリは PostgreSQL 18 を対象としています。バージョンに依存する各節には、該当する場合、古いメジャーバージョン向けの代替手段が記載されています。最初にserver_version_numを確認してください。権限やバージョンの違いでクエリが失敗した場合は、推測せず、制約として報告してください。