こんにちは。今日はPostgreSQLの「裏側」、システムカタログの話をしようと思う。
普段開発していると、`pg_class`や`pg_type`あたりはなんとなく耳にするかもしれないけれど、`pg_attribute`を意識したことはあるだろうか？
正直なところ、アプリケーションを書いているだけなら、このテーブルに直接触れることはまずない。でも、データベースの内部で「何が起きているか」を理解し、メタデータを使ったツール開発や高度なクエリ最適化、あるいは「泥沼のトラブルシュート」をするとき、こいつは最強の相棒になるんだ。
今日は、そんな渋い存在である`pg_attribute`の正体と、現場で意外と役に立つ使い方を深掘りしていくよ。
—
`pg_attribute` とは何か？
一言で言うなら、「テーブルの『骨組み』を記述する台帳」だ。
PostgreSQLは、テーブルの列（カラム）情報をすべてこの`pg_attribute`というシステムカタログに書き込んでいる。テーブル名だけでなく、列の名前、データ型、列の並び順（attnum）、さらにはその列が削除されているかどうかまで、すべてここに刻まれているんだ。
なぜこれが重要なのか？
例えば、`SELECT ` を実行したとき、PostgreSQLは裏でこの`pg_attribute`を覗きに行っている。「あ、このテーブルにはIDと名前と作成日があるな。順番はこうだな」という具合にね。
つまり、データベースの構造を「動的」に制御したいとき、このテーブルは避けて通れない場所なんだ。
—
実際に中身を覗いてみよう
まずは、自分の環境でどんなデータが入っているか見てみるのが一番早い。適当なテーブルを作って、その詳細を叩いてみようか。
— まず適当なテーブルを用意
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username TEXT NOT NULL,
email TEXT
);
— pg_attribute から情報を引き抜く
SELECT
attname AS column_name,
atttypid::regtype AS data_type,
attnum AS position,
attnotnull AS is_not_null
FROM pg_attribute
WHERE attrelid = ‘users’::regclass
AND attnum > 0 — システムカラム（oidなど）を除外
ORDER BY attnum;
これを見てどう思う？ `attnum`が列の順番を表していて、`atttypid::regtype`とキャストすることでデータ型が直感的に読めるようになる。ここを操作するだけで、自分のデータベースの「設計図」をSQLで自由自在に抽出できるんだ。
—
現場で役に立つ「ユースケース」
ただ眺めるだけじゃ面白くないよね。実務で僕が実際に使った例をいくつか紹介するよ。
1. テーブルの「全カラム」をプログラムから動的に取得したいとき
ORMを使わずに汎用的なデータ処理ツールを作るとき、テーブルの定義をハードコーディングしたくないことってあるよね。そんなとき、`pg_attribute`をクエリすれば、どんなテーブルが来ても自動的にカラム名をリストアップして処理する仕組みが作れる。
2. 「削除されたはずの列」がゴミとして残っていないか確認する
PostgreSQLで`ALTER TABLE DROP COLUMN`を実行しても、内部的には物理削除されるまで少し時間がかかることがある。`pg_attribute`には`attisdropped`というカラムがあるんだけど、これを見れば「論理的には消したけど、まだ物理的に残っている幽霊カラム」がいないか確認できる。大規模なマイグレーションの後にクリーンアップできているか確認する際、僕はよくこれを使うんだ。
—
エンジニアへのアドバイス：直接いじるな、心で読め
ここで一つ、僕からの強い警告を。
「`pg_attribute` を直接 `UPDATE` や `DELETE` してはいけない」。
これはシステムカタログだ。これを直接書き換えるということは、PostgreSQLの整合性を自ら破壊する行為に等しい。もし「このカラム名を無理やり変えたい」と思っても、必ず `ALTER TABLE RENAME` を使うこと。システムカタログはあくまで「読み取り専用の辞書」として扱うのが、一流のエンジニアの流儀だよ。
—
まとめ：深く知ることは「自信」に変わる
`pg_attribute` を知ることは、単なる知識の蓄積じゃない。
「データベースが裏でどうやって列を管理しているか」という仕組みを知っているだけで、例えば `SELECT ` がなぜ遅くなる可能性があるのか、テーブルの列順序を入れ替えると何が起きるのか、そういった「勘」が働くようになる。
現場で「なぜかクエリが通らない」「メタデータが整合していない気がする」というトラブルに遭遇したとき、このカタログを叩く勇気があれば、君はもう一段階上のレベルに行けるはずだ。
もし興味があれば、自分のプロジェクトのデータベースで `SELECT FROM pg_attribute LIMIT 10;` を打ってみてほしい。そこには、君のアプリケーションを支える「骨組み」が整然と並んでいるはずだよ。
それでは、また次回のブログで。ハッピー・コーディング！
コメント