Chaque table a plusieurs colonnes système qui sont implicitement définies 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 ; mettre un nom entre guillemets ne vous permettra pas d'échapper à ces restrictions). Vous n'avez pas vraiment besoin de vous préoccuper de ces colonnes, simplement sachez qu'elles existent.
L'identifieur objet (object ID) d'une ligne. Cette colonne est seulement présente si la table a été créée en utilisant WITH OIDS ou si la variable de configuration default_with_oids était activée. Cette colonne est de type oid (même nom que la colonne) ; voir la Section 8.12, « Types identifiants d'objets » pour plus d'informations sur ce type.
L' OID de la table contenant cette ligne. Cette colonne est particulièrement utile pour les requêtes qui font des sélections à partir de hiérarchies héritées (voir Section 5.8, « Héritage ») puisque, sans elle, il est difficile de dire de quelle table provient une ligne. tableoid peut être joint à la colonne oid de pg_class pour obtenir le nom de la table.
L'identifieur (ID de transaction) de la transaction d'insertion de cette version de la ligne (une version de ligne est un état individuel d'une ligne ; chaque mise à jour d'une ligne crée une nouvelle version de ligne pour la même ligne logique).
L'identifieur de commande (à partir de zéro) au sein de la transaction d'insertion.
L'identifieur (ID de transaction) de la transaction de suppression, ou zéro pour une version de ligne non effacée. Il est possible pour cette colonne d'être non NULL dans une version de ligne 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.
L'identifieur de commande au sein d'une transaction de suppression, ou zéro.
La localisation physique de la version de ligne au sein de sa table. Notez que, bien que le ctid peut être utilisé pour trouver la version de ligne très rapidement, le ctid d'une ligne change chaque fois qu'il est mis à jour ou déplacé par la commande VACUUM FULL. Donc, ctid est inutile en tant qu'identifieur de ligne à long terme. L'OID, ou encore mieux un numéro de série défini par l'utilisateur, devrait être utilisé pour identifier des lignes logiques.
Les OID sont des nombres de 32 bits et sont attribués d'un seul compteur. 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 OID sont uniques, sauf si vous prenez les précautions nécessaires. Si vous avez besoin d'identifier les lignes d'une table, l'utilisation d'un générateur de séquence est fortement recommandée. Néanmoins, les OID peuvent aussi être utilisés à condition que quelques précautions soient prises :
Une contrainte unique doit être ajoutée sur la colonne OID de chaque table pour laquelle l'OID est utilisée pour identifier les lignes. Quand une telle contrainte unique (ou un index unique) existe, le système fait attention à ne pas générer un OID correspondant à celui d'une ligne déjà existante (bien sûr, ceci est seulement possible si la table contient moins de 232 (4 milliards) lignes et, en pratique, la taille de la table a tout intérêt à être bien plus petite que ça, sinon les performances pourraient en souffrir).
Les OID ne doivent jamais être supposés uniques entre tables ; utilisez la combinaison de tableoid et de l'OID de la ligne si vous avez besoin d'un identifieur sur la base complète.
Les tables en question devraient être créées en utilisant WITH OIDS. À partir de PostgreSQL™ 8.1, WITHOUT OIDS est l'option par défaut.
Les identifieurs de transaction sont aussi des nombres de 32 bits. Dans une base de données de longue vie, il est possible que les ID de transaction bouclent sur eux-mêmes. Ceci n'est pas un problème fatal avec des procédures de maintenance appropriées ; voir le Chapitre 22, Planifier les tâches de maintenance pour les détails. Par contre, il est imprudent de dépendre de l'aspect unique des ID de transaction à long terme (plus d'un milliard de transactions).
Les identifieurs 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 lignes traitées.
Contraintes