| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Chapitre 5. Définition des données | Avance rapide | Suivant |
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.
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 la Section 8.12 pour plus d'informations sur ce type.
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. tableoid peut être joint à la colonne oid de pg_class pour obtenir le nom de la table.
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.)
L'identifiant de commande (à partir de zéro) au sein de la transaction d'insertion.
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 NULL 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.
L'identifiant de commande au sein d'une transaction de suppression, ou zéro.
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 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 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 dans 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 devrait être créée sur la colonne OID de chaque table pour laquelle l'OID sera utilisée pour identifier les lignes.
Les OID ne devraient 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 identifiant sur la base complète.
Les tables en question devraient être créées en utilisant WITH OIDS pour s'assurer de la compatibilité avec les versions futures de PostgreSQL. Il est planifié que WITHOUT OIDS deviendra l'option par défaut.
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 le 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.
| Précédent | Sommaire | Suivant |
| Contraintes | Niveau supérieur | Héritage |