5.2. Colonnes Systèmes

Chaque table a plusieurs colonnes systèmes qui sont implicitement définis par le système. De ce fait, ces noms ne peuvent être utilisés comme noms de colonnes définis par l'utilisateur. (Notez que ces restrictions sont différentes, si le nom est un mot-clé ou pas; citez un nom ne vous permettra pas d'échapper à ces restrictions.) Vous n'avez pas vraiment besoin de vous préoccuper de ces colonnes, simplement savoir qu'elles existent.

oid

L'identifiant objet (object ID) d'une rangée. Ceci est un numéro de série qui est automatiquement rajouté par PostgreSQL à toutes les rangées de tables (sauf si la table a été créée avec WITHOUT OIDS, auquel cas cette colonne n'est pas présente). Cette colonne est de type oid (même nom que la colonne); voir Section 8.11 pour plus d'informations sur ce type.

tableoid

L' OID de la table contenant cette rangée. Cette colonne est particulièrement utile pour les requêtes qui sélectionnent de hiérarchies héritées, puisque sans elle, il est difficile de dire de quelle table vient une rangée. Le tableoid peut être joint à la colonne oid de pg_class pour obtenir le nom de la table.

xmin

L'identité (transaction ID) de la transaction d'insertion de cette version de la rangée. (Une version de rangée est un état individuel d'une rangée; chaque mise à jour d'une rangée crée une nouvelle version de rangée pour la même rangée logique.)

cmin

L'identifiant de commande (à partir de zéro) au sein de la transaction d'insertion.

xmax

L'identité (transaction ID) de la transaction de suppression, ou zéro pour une version de rangée non effacée. Il est possible pour cette colonne d'être non nulle dans une version de rangée visible: Ceci indique normalement 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 d'une transaction de suppression, ou zéro.

ctid

La localisation physique de la version de rangée au sein de sa table. Notez que bien que le ctid peut être utilisé pour trouver la version de rangée très rapidement, le ctid d'une rangée changera chaque fois qu'il est mis à jour ou déplacé par ctid changera à chaque lancement de la commande VACUUM FULL. Donc ctid est inutile en tant qu'identifiant de rangée à long terme. L'OID, ou encore mieux un numéro de série définie par l'utilisateur, devrait être utilisé pour identifier des rangées logiques.

Les OIDs sont des nombres de 32 bits et sont attribués d'un seul compteur sur tout le cluster. Dans une base de données grande ou vieille, il est possible que le compteur boucle sur lui-même. Donc il est peu pertinent de partir du principe que les OIDs sont uniques, sauf si vous prenez les précautions nécessaires. La marche a suivre recommandée lorsqu'on utilise les OIDs pour l'identification de rangée est de créer une contrainte unique sur la colonne OID de chaque table pour laquelle l'OID sera utilisé. Ne jamais supposer que les OIDs sont uniques sur toutes les tables; utilisez la combinaison de tableoid et OID de rangée si vous avez besoin d'un identifiant unique sur toute la base. (Les versions futures de PostgreSQL auront probablement un compteur OID pour chaque table, pour que le tableoid puisse être inclus pour arriver à un identifiant unique globale.)

Les identifiants de transaction sont aussi des nombres de 32 bits. Dans une base de données de longue vie, il est possible pour les ID de transaction de boucler sur eux-mêmes. Ceci n'est pas un problème fatal avec des procédures de maintenance appropriées; voir Chapitre 21 pour les détails. Il est, par contre, imprudent de dépendre de l'aspect unique des ID de transaction à long terme (plus d'un milliard de transactions).

Les identifiants de commande sont aussi des nombres de 32 bits. Ceci crée une limite dure de 232 (4 milliards) commandes SQL au sein d'une seule transaction. En pratique, cette limite n'est pas un problème --- notez que la limite est sur le nombre de commandes SQL, pas le nombre de rangées traitées.