Les identifiants d'objets (OID) sont utilisés en interne par PostgreSQL™ comme clés primaires de différentes tables système. Les OID ne sont pas ajoutés aux tables créées par l'utilisateur sauf si WITH OIDS est spécifié lors de la création de la table ou si la variable de configuration default_with_oids est activée. Le type oid représente un identifiant d'objet. Il a aussi différents types alias pour le type oid : regproc, regprocedure, regoper, regoperator, regclass et regtype. Le Tableau 8.19, « Types identifiants d'objet » donne un aperçu.

Le type oid est actuellement un entier de quatre octets. Il n'est pas suffisamment grand pour garantir l'unicité dans une grosse base de données, voire même dans une très grosse table. Du coup, l'utilisation d'une colonne OID comme clé primaire d'une table créée par un utilisateur est déconseillée. Les OID sont surtout destinés à être des références vers les tables système.

Le type oid lui-même dispose de peu d'opérations à part la comparaison. Néanmoins, il peut être converti en entier (integer) et manipulé en utilisant les opérateurs habituels des entiers (attention aux possibles confusions entre les entiers signés et non signés si vous le faites).

Les types alias de l'OID n'ont pas d'opérations à eux sauf pour les routines spécialisées en entrée et en sortie. Ces routines sont capables d'accepter et d'afficher des noms symboliques pour les objets systèmes, plutôt que la valeur numérique brute que le type oid utiliserait. Les types alias permettent de simplifier la recherche des valeurs OID pour les objets. Par exemple, pour examiner les lignes pg_attribute en relation avec une table ma_table, vous pourriez écrire

SELECT * FROM pg_attribute WHERE attrelid = 'ma_table'::regclass;

plutôt que

SELECT * FROM pg_attribute
WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'ma_table');

Bien que cela ne semble pas si difficile, c'est toujours trop simplifié. Une sous-sélection bien plus compliqué peut être nécessaire pour sélectionner le bon OID s'il existe plusieurs tables nommées ma_table dans différents schémas. Le convertisseur d'entrées regclass gère la recherche de la table suivant le paramétrage du chemin des schémas et il fera donc la « bonne recherche » automatiquement. De façon similaire, convertir un OID d'une table en regclass est facile pour l'affichage symbolique d'un OID numérique.

Tous les types alias d'OID acceptent des noms avec un préfixe de schéma, et affichent des noms préfixés par un schéma si l'objet ne peut être trouvé dans le chemin de recherche courant sans préfixe de schéma. Les types alias regproc et regoper n'acceptent que des noms uniques en entrée (sans surcharge), si bien qu'ils sont d'un usage limité. Dans la plupart des cas, regprocedure ou regoperator sont plus appropriés. Pour regoperator, les opérateurs unaires sont identifiés en écrivant NONE pour les opérandes non utilisés.

Une propriété supplémentaire des types d'alias OID est que, si une constante d'un de ces types apparaît dans une expression stockée (comme l'expression par défaut d'une colonne ou une vue), elle crée une dépendance sur l'objet référencé. Par exemple, si une colonne a une expression par défaut nextval('ma_seq'::regclass), PostgreSQL™ comprend que l'expression par défaut dépend de la séquence ma_seq ; le système ne permettra pas la suppression de la séquence sans que l'expression par défaut ne soit elle-même supprimée.

Un autre type d'identifiant utilisé par le système est xid, ou identifiant de transaction (abrégé xact). C'est le type de données des colonnes systèmes xmin et xmax. Les identifiants de transactions sont des quantités sur 32 bits.

Un troisième type d'identifiant utilisé par le système est cid, ou identifiant de commande. C'est le type de données des colonnes systèmes cmin et cmax. Les identifiants de commandes sont aussi des quantités sur 32 bits.

Un dernier type d'identifiant utilisé par le système est tid, ou identifiant de ligne (tuple). C'est le type de données des colonnes système ctid. Un tuple est une paire (numéro de bloc, index de tuple dans le bloc) qui identifie l'emplacement physique de la ligne dans sa table.

Les colonnes systèmes sont expliquées plus en détail dans la Section 5.4, « Colonnes système ».