他のバージョンの文書 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

5.2. システム列

すべてのテーブルには、システムによって暗黙的に定義されたシステム列がいくつかあります。 そのため、システム列の名前はユーザ定義列の名前として使うことはできません。 (これらの制約は名前がキーワードであるかどうかとは関係ありません。 つまり、名前を引用符で囲んでもこの制約を回避することはできません。) システム列については、あまり意識する必要はありません。 これらが存在することを知っていれば十分です。

oid

行のオブジェクト識別子(オブジェクトID)です。 これはPostgreSQLがすべてのテーブル行 (OID列を生成させないWITHOUT OIDSをつけてテーブルを作成した場合を除き)に自動的に付与する連番の番号です。 この列の型はoid(列名と同じ)です。 この型についての詳細は項8.11を参照してください。

tableoid

この行を含むテーブルのOIDです。 この列は特に、継承階層からの選択問い合わせでは便利です。 この列がないと、どのテーブルからその行が来たのかわかりにくいからです。 tableoidはテーブル名を得るためにpg_classoid列に結合することができます。

xmin

あるバージョンの行用の挿入トランザクションの識別情報(トランザクション ID)です。 (行のバージョンとは、行の個別の状態です。行が更新される度に、同一の論理的な行に対する新しいバージョンの行が作成されます。)

cmin

挿入トランザクション内の(0から始まる)コマンド識別子です。

xmax

削除トランザクションの識別情報(トランザクションID)です。 削除されていない行ではゼロです。 可視のバージョンの行でこの列が非ゼロの場合があります。 これは通常、削除トランザクションがまだコミットされていないこと、または、削除の試行がロールバックされたことを意味しています。

cmax

削除トランザクション内のコマンド識別子、もしくはゼロです。

ctid

テーブル内における、行バージョンの物理的位置を表します。 ctid は行バージョンを素早く見つけるために使うことができますが、行のctidは更新されるたびに、あるいはVACUUM FULL で移動させられるたびに変わります。 したがって、ctidは長期の行識別子としては使えません。 論理行を識別するためには、OID、あるいはさらによいのはユーザ定義の通番数、を使うべきです。

OIDは32ビット量であり、クラスタ全体で一つのカウンタです。 大規模、もしくは、長期間使用するデータベースでは、カウンタが一周してしまう可能性があります。 従い、一意性を確保するための手順を踏んでいない限り、OIDが一意であると仮定してはなりません。 行の識別のためにOIDを使用する場合の推奨手法は、OIDを使用するテーブルそれぞれでOID列に一意性制約を付与することです。 テーブルを跨ってOIDが一意であると仮定してはなりません。 データベース全体での識別子が必要であれば、tableoidと行のOIDの組合せを使用してください。 (今後のPostgreSQLリリースでは、各テーブルでOIDカウンタを分ける予定です。 その場合、tableoidはグローバルな一意識別子となるように含める必要があります。)

トランザクション識別子も32ビット量です。 長期間使用するデータベースでは、トランザクションIDが一周してしまう可能性があります。 これは、適切な保守作業を行なうことで、致命的な問題にはなりません。 詳細は第21章を参照してください。 しかし、長期に渡ってトランザクションIDの一意性に依存することは賢明ではありません。

コマンド識別子もまた、32ビット量です。 このため、単一トランザクション内のコマンド数には232(40億)個までという制限が発生します。 実際、この制限は問題にはなりません。 これはSQLコマンド数に対する制限であり、処理される行数に対する制限ではないことに注意してください。