全てのテーブルには、システムによって暗黙的に定義されたシステム列がいくつかあります。 そのため、システム列の名前はユーザ定義列の名前として使うことはできません （これらの制約は名前がキーワードであるかどうかとは関係ありません。 つまり、名前を引用符で囲んでもこの制約を回避することはできません）。 システム列については、あまり意識する必要はありません。 これらが存在することを知っていれば十分です。
行のオブジェクト識別子（オブジェクトID）です。 この列はWITH OIDSを付けた場合と、その時にdefault_with_oidsが設定されていた場合に作成されます。 この列の型はoid（列名と同じ）です。この型についての詳細は項8.16を参照してください。
この行を含むテーブルのOIDです。
この列は特に、継承階層からの選択問い合わせでは便利です（項5.8を参照してください）。
この列がないと、どのテーブルからその行が来たのかわかりにくいからです。
tableoidはテーブル名を得るためにpg_classのoid列に結合することができます。
あるバージョンの行用の挿入トランザクションの識別情報（トランザクションID）です （行のバージョンとは、行の個別の状態です。行が更新される度に、同一の論理的な行に対する新しいバージョンの行が作成されます）。
挿入トランザクション内の（0から始まる）コマンド識別子です。
削除トランザクションの識別情報（トランザクションID）です。 削除されていない行ではゼロです。 可視のバージョンの行でこの列が非ゼロの場合があります。 これは通常、削除トランザクションがまだコミットされていないこと、または、削除の試行がロールバックされたことを意味しています。
削除トランザクション内のコマンド識別子、もしくはゼロです。
テーブル内における、行バージョンの物理的位置を表します。 ctid は行バージョンを素早く見つけるために使うことができますが、行のctidは更新される、あるいはVACUUM FULLで移動させられると変わります。 したがって、ctidは長期の行識別子としては使えません。 論理行を識別するためには、OID、あるいはさらに良いのはユーザ定義の通番数を使うべきです。
OIDは32ビット数であり、クラスタ全体で1つのカウンタです。 大規模、もしくは長期間使用するデータベースでは、カウンタが一周してしまう可能性があります。 そのため、一意性を確保するための手順を踏んでいない限り、OIDが一意であると仮定してはなりません。 もしテーブル内の行を同定する必要がある場合は、シーケンス生成を使用することを強く推奨します。 しかし、OIDはいくつかの注意を払うことによりシーケンスと同様に使用することができます。
ユニーク制約は、OIDが行を同定するために使用されるようなテーブルのOID列に作成されなくてはいけません。 このような一意制約（もしくは一意インデックス）が存在する場合は、システムは既存の行に一致するようなOIDを生成しません。 （もちろん、これはテーブルの行数が232（40億）より少ない場合に可能となります。パフォーマンスを考慮すると、実際には行数はそれよりずっと少ない方がよいでしょう。）
OIDは、複数のテーブルをまたがって一意であると仮定してはなりません。データベース全体での識別子が 必要な場合はtableoidと行OIDを組み合わせて使用してください。
もちろん、問題にしているテーブルは、WITH OIDSを使用して作成されなくてはいけません。 PostgreSQL 8.1に関して、WITHOUT OIDSはデフォルトです。
トランザクション識別子も32ビット量です。 長期間使用するデータベースでは、トランザクションIDが一周してしまう可能性があります。 これは、適切な保守作業を行うことで、致命的な問題にはなりません。 詳細は第23章を参照してください。 しかし、長期にわたってトランザクションIDの一意性に依存することは賢明ではありません。
コマンド識別子もまた、32ビット量です。 このため、単一トランザクション内のコマンド数には232（40億）個までという制限が発生します。 実際、この制限は問題にはなりません。 これはSQLコマンド数に対する制限であり、処理される行数に対する制限ではないことに注意してください。 またPostgreSQL 8.3に関しては、データベースの内容を実際に変更するコマンドのみがコマンド識別子を消費します。