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 tables partitionnées
(voir Section 5.11) ou des hiérarchies
d'héritage (voir Section 5.10). En effet, il est
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.
xmin #L'identifiant (ID) 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.)
cmin #L'identifiant de commande (à partir de zéro) au sein de la transaction d'insertion.
xmax #L'identifiant (ID) 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.
cmax #L'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 des nombres sur 32 bits. Dans une base de données âgée, il est possible que les identifiants de transaction bouclent. Cela n'est pas un problème fatal avec des procédures de maintenance appropriées ; voir le Chapitre 25 pour les détails. Il est, en revanche, imprudent de considérer l'unicité des identifiants de transaction sur le long terme (plus d'un milliard de transactions).
Les identifiants de commande sont aussi des nombres sur 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.