【実務・中級編】 pg_type – PostgreSQL

やあ、今日もデータベースと格闘してる？

PostgreSQLを使っていると、ふとした瞬間に「今、このテーブルで使われてる型って何だっけ？」「ENUM型の中身をサクッと確認したいんだけど、どうやるのが一番スマート？」なんて思うこと、あるよね。

ドキュメントの隅っこに書かれているような話だけど、実務でこの「システムカタログ」を使いこなせると、トラブルシュートや設計の確認スピードが段違いに変わる。今日は、PostgreSQLの屋台骨を支える `pg_type` について、現場的な視点で深掘りしてみよう。

—

`pg_type` ってそもそも何者？

一言で言えば、PostgreSQLが知っている「型」の辞書だ。

int4やtextといった組み込み型から、自分で定義したENUM型、さらにはテーブルを作った時に裏で自動生成される複合型（コンポジット型）まで、すべてここに登録されている。

「型」はデータベースの心臓部だ。クエリを実行するとき、PostgreSQLは `pg_type` を参照して、「このデータはメモリ上でどう扱うべきか」「どうやってキャストするか」を判断している。つまり、ここを覗くことは、PostgreSQLの脳内を覗くことに等しいんだ。

—

現場でよく使う「pg_type」活用シーン

マニュアルを丸暗記する必要なんてない。僕らが実務でよくやる「これだけは知っておけ」というクエリを紹介するね。

1. ENUM型の定義をサクッと確認したい時

開発中、「あれ？このENUM型、どんな値が定義されてたっけ？」と迷うこと、あるよね。`psql` で `\dT` を使うのもいいけど、SQLで抽出した方が柔軟に扱える。

SELECT
t.typname AS enum_name,
e.enumlabel AS enum_value
FROM pg_type t
JOIN pg_enum e ON t.oid = e.enumtypid
ORDER BY t.typname, e.enumsortorder;

これだけで、現在定義されているすべてのENUMとその値が一覧できる。マイグレーションの確認や、ドキュメント生成の自動化スクリプトを作る時に重宝するよ。

2. 「これ、どのテーブルで使われてる型だっけ？」という時

複合型（テーブルを定義すると自動で作られるあの型）を使っていると、「この型、どこで使われてるんだ？」と迷子になることがある。そんな時は `pg_attribute` と組み合わせるのが鉄板だ。

SELECT
n.nspname AS schema_name,
t.typname AS type_name,
c.relname AS table_name
FROM pg_type t
JOIN pg_class c ON t.typrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE t.typtype = ‘c’; — ‘c’ はコンポジット型（複合型）を意味する

これを覚えておくと、複雑なスキーマ設計の解析や、古いコードの整理をする時に「ここを消しても大丈夫か？」という判断が安全にできるようになる。

—

注意点：直接いじるのは「禁じ手」

さて、これだけ便利だと「じゃあ `pg_type` を直接UPDATEして型定義を変えちゃえばいいんじゃ？」と思うかもしれない。

絶対にダメだよ。

システムカタログはPostgreSQLの整合性を保つための聖域だ。ここを無理やり書き換えると、最悪の場合データベースが起動しなくなったり、データが読み出せなくなったりする。型を変えたいなら、必ず `ALTER TYPE` や `DROP TYPE` といった正しいコマンドを使うこと。これが、DBエンジニアとしての最低限のたしなみだね。

—

まとめ：カタログを覗くと「見えないもの」が見えてくる

`pg_type` を使いこなせるようになると、PostgreSQLが単なる「データの入れ物」ではなく、「型システムによって厳密に管理された高度なエンジンの集合体」であることが分かってくるはずだ。

困ったときはカタログを見る： `pg_type` をはじめ、`pg_class` や `pg_attribute` は僕らの強力な味方だ。
読み取り専用で使う： 現場のルールとして、カタログへの直接操作は厳禁。
自動化に活かす： こういった情報をSQLで抽出できると、監視スクリプトやツール作成の幅が劇的に広がる。

「データベースがどうやって動いているのか」を理解しているエンジニアは、トラブルに強い。今日から `psql` を開いた時に、少しだけ `pg_type` に挨拶してみてほしい。きっと、今まで見えなかったPostgreSQLの構造が見えてくるはずだよ。

それじゃ、また現場で会おう！