Chaque table contient plusieurs colonnes système implicitement définies par le système. De ce fait, leurs noms ne peuvent pas être utilisés comme noms de colonnes utilisateur (ces restrictions sont distinctes de celles sur l'utilisation de mot-clés ; mettre le nom entre guillemets ne permet pas d'échapper à cette règle). Il n'est pas vraiment utile de se préoccuper de ces colonnes, mais au minimum de savoir qu'elles existent.
tableoid
L'OID de la table contenant la ligne. Cette colonne est
particulièrement utile pour les requêtes qui utilisent des hiérarchies
d'héritage (voir Section 5.10). Il est, en effet,
difficile, en son absence, de savoir de quelle table provient une ligne.
tableoid
peut être joint à la colonne oid de
pg_class pour obtenir le nom de la table.
xminL'identifiant (ID de transaction) de la transaction qui a inséré cette version de la ligne. (Une version de ligne est un état individuel de la ligne ; toute mise à jour d'une ligne crée une nouvelle version de ligne pour la même ligne logique.)
cminL'identifiant de commande (à partir de zéro) au sein de la transaction d'insertion.
xmaxL'identifiant (ID de transaction) de la transaction de suppression, ou zéro pour une version de ligne non effacée. Il est possible que la colonne ne soit pas nulle pour une version de ligne visible ; cela indique habituellement que la transaction de suppression n'a pas été effectuée, ou qu'une tentative de suppression a été annulée.
cmaxL'identifiant de commande au sein de la transaction de suppression, ou zéro.
ctid
La localisation physique de la version de ligne au sein de sa table.
Bien que le ctid puisse être utilisé
pour trouver la version de ligne très rapidement, le
ctid d'une ligne change si
la ligne est actualisée ou déplacée par un VACUUM FULL.
ctid est donc inutilisable comme
identifiant de ligne sur le long terme. Il est préférable d'utiliser
la clé primaire pour identifier les lignes logiques.
Les identifiants de transaction sont aussi des nombres de 32 bits. Dans une base de données âgée, il est possible que les ID de transaction bouclent. Cela n'est pas un problème fatal avec des procédures de maintenance appropriées ; voir le Chapitre 24 pour les détails. Il est, en revanche, imprudent de considérer l'unicité des ID de transaction sur le long terme (plus d'un milliard de transactions).
Les identifiants de commande sont aussi des nombres de 32 bits. Cela crée une limite dure de 232 (4 milliards) commandes SQL au sein d'une unique transaction. En pratique, cette limite n'est pas un problème -- la limite est sur le nombre de commandes SQL, pas sur le nombre de lignes traitées. De plus, seules les commandes qui modifient réellement le contenu de la base de données consomment un identifiant de commande.