★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

8.19. オブジェクト識別子データ型 #

オブジェクト識別子(OID)はPostgreSQLの内部で様々なシステムテーブルの主キーとして使用されます。 oidデータ型はオブジェクト識別子を表します。 oidには別名型もいくつかあります。 reg何とかとそれぞれ名付けられたoidの様々なエイリアスの型は表 8.26からその概要を見ることができます。

oidデータ型は現在、符号なし4バイト整数として実装されています。 このため、大きなデータベース内でデータベース単位での一意性や個別の大きなテーブルで一意性を提供するためには十分な大きさではありません。

oidデータ型自体は、比較以外の演算はほとんど行いません。 しかし、整数としてキャストすることもでき、その場合標準の整数演算子を使用して操作することができます。 (これを行うと、符号付きと符号なしの間で混乱が起きかねないことに注意してください。)

OIDの別名データ型は、専用の入出力ルーチン以外には演算を行いません。 これらのルーチンでは、oid型が使用するような未加工の数値ではなく、システムオブジェクト用のシンボル名を受け入れたり表示したりできます。 別名データ型により、オブジェクトのOID値の検索が簡単になります。 例えば、mytableテーブルに関連したpg_attribute行を確認するには、以下のように記述することができます。

SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;

次のように記述する必要はありません。

SELECT * FROM pg_attribute
  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');

後者もそう悪くないように見えますが、これは過度に単純化されています。 異なるスキーマにmytableテーブルが複数ある場合には、正しいOIDを選択するために、より複雑な副SELECTが必要となります。 regclass入力変換ではスキーマパスの設定に従ってテーブル検索を扱いますので、自動的に正しい検索を行います。 同様に、テーブルのOIDをregclassにキャストすることは、数値のOIDのシンボル表示に便利です。

表8.26 オブジェクト識別子データ型

型名参照説明値の例
oidすべて数値オブジェクト識別子564182
regclasspg_classリレーション名pg_type
regcollationpg_collation照合名"POSIX"
regconfigpg_ts_configテキスト検索設定english
regdictionarypg_ts_dictテキスト検索辞書simple
regnamespacepg_namespace名前空間名pg_catalog
regoperpg_operator演算子名+
regoperatorpg_operator引数の型を持つ演算子*(integer,​integer) or -(NONE,​integer)
regprocpg_proc関数名sum
regprocedurepg_proc引数の型を持つ関数sum(int4)
regrolepg_authidロール名smithee
regtypepg_typeデータ型の名前integer

名前空間でグループ化されたオブジェクトのOID別名型はすべてスキーマ修飾名を受け入れ、出力時にスキーマ修飾名を表示します。 ただし、現在の検索パスでオブジェクトが見つけられなければ、修飾せずに出力します。 例えば、myschema.mytableregclassという入力を(そのようなテーブルがあれば)許容します。 この値の出力は現在の検索パス次第でmyschema.mytableもしくは単にmytableと出力されるでしょう。 regprocregoper別名型は、一意な(オーバーロードしていない)名前のみを入力として受け入れるため、これらの使用には限度があります。 ほとんどの場合、regprocedureまたはregoperatorを使用するのが適切です。 regoperatorの場合、単項演算子は未使用のオペランドをNONEと記述することによって指定されます。

これらの型の入力を許容する関数はトークンの間に空白を入れることを許容し、二重引用符で囲まれたものを除き大文字は小文字に折りたたみます。 これはオブジェクト名がSQLで記述される方法と同じような文法のルールとするための動作です。 逆に出力する関数は有効なSQL識別子となるように必要に応じて二重引用符を使用します。 例えば、Foo(Fが大文字)という2つの整数型の引数を持つ関数のOIDは' "Foo" ( int, integer ) '::regprocedureとして入力できます。 出力は"Foo"(integer,integer)のようになります。 関数名も引数の型名も共にスキーマ修飾することもできます。

PostgreSQLに組み込まれている多くの関数はテーブルやそれ以外の種類のデータベースオブジェクトのOIDを受け入れ、利便性のために regclass(もしくは適切なOIDのエイリアスである型)を取るものとして定義されています。 これはオブジェクトのOIDをわざわざ手動で調べる必要が無く、単にその名前を文字列として入力すれば良いことを意味します。 例えば、 nextval(regclass)関数はシーケンスリレーションのOIDを引数に取りますが、このように呼び出すことができます。


nextval('foo')              シーケンスfooへの操作
nextval('FOO')              上と同じ
nextval('"Foo"')            シーケンスFooへの操作
nextval('myschema.foo')     myschema.fooへの操作
nextval('"myschema".foo')   上と同じ
nextval('foo')              fooのサーチパスの検索

注記

そのような関数の引数を装飾のない文字列として記載した場合、それはregclass型(もしくは適切な型)の定数になります。 これは実際には単にOIDなので、スキーマの再割り当てなどで後からリネームされたとしても最初に識別されたオブジェクトを追跡します。 この早期バインディング(early binding)の動作は列のデフォルトを参照する列やビューにとっては望ましい動作です。 しかし、オブジェクトの参照を実行時に行う遅延バインディング(late binding)が望ましいこともあります。 遅延バインディングの動作とするためには、定数はregclassの代わりにtextの定数として配置してください。

nextval('foo'::text)      foo is looked up at runtime

to_regclass()関数とその兄弟は実行時に参照させるために使用することもできます。 詳細は表 9.72を参照ください。

regclassのもう一つの実用的な使用例はそのようなOIDを直接提供しないinformation_schemaビューにリストされたテーブルのOIDを参照することです。 例えば、テーブルのOIDを必要とするpg_relation_size()関数を呼び出したい場合を考えます。 上記のルールを考慮すると、正しい方法は以下のとおりです。

SELECT table_schema, table_name,
       pg_relation_size((quote_ident(table_schema) || '.' ||
                         quote_ident(table_name))::regclass)
FROM information_schema.tables
WHERE ...

quote_ident()関数は必要に応じて二重引用符をつけます。 より簡単そうに思われる

SELECT pg_relation_size(table_name)
FROM information_schema.tables
WHERE ...

という方法は推奨されません。 テーブルがサーチパスの範囲外にあったり、引用符付けを必要とする名前であった場合に失敗するためです。

ほとんどのOID別名型のさらなる属性は依存性の作成です。 これらの型の1つの定数が格納された式内に存在する場合(列のデフォルト式やビューなど)、参照されるオブジェクトへの依存性を生成します。 例えば、列がnextval('my_seq'::regclass)というデフォルト式を持つ場合、PostgreSQLはデフォルト式がmy_seqシーケンスに依存することを理解します。 システムは先にこのデフォルト式が削除されない限り、このシーケンスを削除させません。 代わりにnextval('my_seq'::text)を使用しても依存性は作成されません。 (このプロパティの例外はregroleです。 ストアド式では、この型の定数は使用できません。)

システムが使用するもう1つの識別子の型はxid、すなわちトランザクション(略してxact)識別子です。 これはxminシステム列およびxmaxシステム列のデータ型です。 トランザクション識別子は32ビット長です。 文脈によっては64ビットに変形したxid8が使われます。 xidの値と違い xid8の値は厳密に単調増加し、データベースクラスタのライフタイムの中で再利用されることはありません。 詳細は74.1を参照してください。

システムが使用する3つ目の識別子はcid、すなわちコマンド識別子です。 これはcminシステム列およびcmaxシステム列のデータ型です。 コマンド識別子も32ビット長です。

システムが使用する最後の識別子はtid、すなわちタプル識別子(行識別子)です。 これはctidシステム列のデータ型です。 タプルIDはテーブル内の行の物理的位置を識別するための組(ブロック番号、ブロック内のタプルインデックス)です。

(システム列の詳細は5.5で説明します。)