PostgreSQLの「心臓部」を覗き見よう：システムカタログ（pg_catalog）との付き合い方
現場でPostgreSQLを触っていると、「あれ、このテーブルの定義、今どうなってるんだっけ？」「特定の型のカラムだけを一括で抽出したいな」なんて場面にぶつかることはありませんか？
そんな時、`\d`コマンドだけで済ませているなら少しもったいない。PostgreSQLには、そのデータベース自身の「戸籍簿」とも言えるシステムカタログ（pg_catalog）という強力な武器が隠されているんです。
今回は、この「データベースのメタデータ」をどう使いこなすか、実務目線で語っていこうと思います。
—
pg_catalogって結局なんなの？
一言で言えば、「PostgreSQL自身がデータベースを管理するために使っている、自分専用のテーブル群」です。
僕たちが普段作るテーブルと同じように、SQLでクエリを投げることができます。例えば、テーブル一覧が見たければ`pg_class`、カラムの情報なら`pg_attribute`、型情報なら`pg_type`といった具合。
「え、そんなの直接触って大丈夫なの？」と思うかもしれませんが、参照するだけなら全く問題ありません。むしろ、これを知っているだけで、デバッグやスキーマ解析のスピードが段違いに変わります。
現場でよく使う「カタログ検索」の例
例えば、特定のテーブルの全カラム名とそのデータ型を、システム的に取得したいとします。そんな時はこんなクエリを投げます。
SELECT
a.attname AS column_name,
t.typname AS data_type
FROM pg_attribute a
JOIN pg_type t ON a.atttypid = t.oid
JOIN pg_class c ON a.attrelid = c.oid
WHERE c.relname = ‘your_table_name’ — ここに調べたいテーブル名
AND a.attnum > 0 — システムカラムを除外
ORDER BY a.attnum;
どうでしょう。GUIツールでポチポチ探すより、遥かに速いし、何より「自動化」できるのが強みですよね。
information_schemaとの付き合い方
ここで一つ、よくある疑問が「`information_schema`と何が違うの？」という話。
実は、`information_schema`はSQL標準に準拠したビューです。一方で`pg_catalog`はPostgreSQL独自の仕様。
- information_schema: 移植性を気にする場合や、汎用的なツールを作るならこちら。
- pg_catalog: PostgreSQL固有の高度な機能（OIDや継承、詳しい統計情報など）まで掘り下げたいならこちら。
現場の運用保守で「PostgreSQLに特化して調査したい」という時は、迷わず`pg_catalog`を選んでください。痒い所に手が届くのは、間違いなくこちらです。
現場のエンジニアへのアドバイス
僕が後輩によく言うのは、「まずは`pg_catalog`のテーブル一覧を一度眺めてみて」ということです。
SELECT relname FROM pg_class WHERE relkind = ‘r’;
これだけで、どんなテーブルが定義されているか、システムが何を隠し持っているかが少し見えてきます。
ただし、一点だけ注意を。「更新（UPDATE/DELETE）は絶対にしないこと」。たまに「システムカタログを直接書き換えて無理やり整合性を直そう」とするツワモノがいますが、それはDBの死を意味します。あくまで「覗き見」にとどめる、これが鉄則です。
まとめ：SQLでSQLを理解する
システムカタログを使いこなせるようになると、データベースは単なる「データの入れ物」ではなく、「クエリ可能な自分の相棒」に変わります。
「今のDBの状態はどうなっているんだろう？」と疑問に思った時、ドキュメントを検索する前に、まずは`pg_catalog`に聞いてみる。そんな癖をつけておくと、トラブルシューティングの際にも圧倒的に早く原因にたどり着けるようになりますよ。
次はぜひ、自分の環境で `SELECT FROM pg_class LIMIT 10;` と打ってみてください。そこから、PostgreSQLの奥深い世界への扉が開きます。
それでは、また次回の記事でお会いしましょう！
コメント