Documentation PostgreSQL 14.22 » Langage SQL » Types de données » Types identifiant d'objet

Précédent | Niveau supérieur | Suivant
8.18. Types domaine | Sommaire | 8.20. Type `pg_lsn`

## 8.19. Types identifiant d'objet

Les identifiants d'objets (OID) sont utilisés en interne par PostgreSQL comme clés primaires de différentes tables système. Le type `oid` représente un identifiant d'objet. Il existe aussi différents types alias pour un `oid`, chacun nommés `reg`quelquechose``. Le Tableau 8.26 en donne un aperçu.

Le type `oid` est à ce jour un entier non signé sur quatre octets. Il n'est, de ce fait, pas suffisamment large pour garantir l'unicité au sein d'une base de données volumineuse, voire au sein d'une très grosse table.

Le type `oid` lui-même dispose de peu d'opérations en dehors de la comparaison. Il peut toutefois être converti en entier (integer) et manipulé par les opérateurs habituels des entiers (attention aux possibles confusions entre les entiers signés et non signés dans ce cas).

Les types alias d'OID ne disposent pas d'opérations propres à l'exception des routines spécialisées de saisie et d'affichage. Ces routines acceptent et affichent les noms symboliques des objets système, plutôt que la valeur numérique brute que le type `oid` utilise. Les types alias permettent de simplifier la recherche des valeurs OID des objets. Par exemple, pour examiner les lignes `pg_attribute` en relation avec une table `ma_table`, on peut é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 semble une bonne solution, c'est un peu trop simplifié. Un sous-select 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 de saisie `regclass` gère la recherche de la table en fonction du paramétrage du parcours des schémas et effectue donc la « bonne recherche » automatiquement. De façon similaire, la conversion d'un OID de table en `regclass` pour l'affichage d'un OID numérique est aisée.

Tableau 8.26. Types identifiant d'objet

Nom | Référence | Description | Exemple
--- | --- | --- | ---
`oid` | tous | identifiant d'objet numérique | `564182`
`regclass` | `pg_class` | relation name | `pg_type`
`regcollation` | `pg_collation` | collation name | `"POSIX"`
`regconfig` | `pg_ts_config` | text search configuration | `english`
`regdictionary` | `pg_ts_dict` | text search dictionary | `simple`
`regnamespace` | `pg_namespace` | namespace name | `pg_catalog`
`regoper` | `pg_operator` | nom d'opérateur | `+`
`regoperator` | `pg_operator` | opérateur avec types d'arguments | `*(integer,​integer)` ou `-(NONE,​integer)`
`regproc` | `pg_proc` | nom de fonction | `sum`
`regprocedure` | `pg_proc` | fonction avec les types des arguments | `sum(int4)`
`regrole` | `pg_authid` | nom de rôle | `smithee`
`regtype` | `pg_type` | nom du type de données | `integer`

Tous les types alias d'OID pour des objets groupés par schéma acceptent des noms qualifiés par le 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 être qualifié. Par exemple, `myschema.mytable` est une saisie acceptée pour `regclass` (s'il y a une telle table). Cette valeur peut être une valeur retournée comme `myschema.mytable`, ou juste `mytable`, selon le chemin de parcours des schémas courant. 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` et `regoperator` sont plus appropriés. Pour `regoperator`, les opérateurs unaires sont identifiés en écrivant `NONE` pour les opérandes non utilisés.

Les entrées de fonction pour ces types permettent les espaces entre tokens, et interpréteront les lettres en majuscules par des minuscules, sauf si elles sont entre guillemets ; ceci est effectué pour rendre les règles de syntaxe similaires à la façon dont les noms d'objets sont écrits en SQL. De même, les retours de fonctions utiliseront les guillements s'il est besoin que la sortie soit un identifiant SQL valide. Par exemple, l'OID d'une fonction nommée `Foo` (avec le `F` majuscule) et prenant deux arguments entiers peut être saisie comme `' "Foo" ( int, integer ) '::regprocedure`. La sortie ressemblera à `"Foo"(integer,integer)`. Les noms de fonction et les noms des types d'arguments peuvent aussi être qualifiés par un nom de schéma.

De nombreuses fonctions internes de PostgreSQL acceptent l'OID d'une table, ou un autre type d'objet de base de données, et pour des raisons de simplicité sont déclarées comme prenant un `regclass` (ou le type d'alias OID approprié). Ceci signifie qu'il n'est pas nécessaire de chercher soi-même l'OID de l'objet, mais qu'il suffit juste de saisir son nom sous sa forme littérale de chaîne. Par exemple, la fonction `nextval(regclass)` prend un OID de relation de séquence, ainsi elle peut être appelée :

    nextval('foo')              opère sur la séquence foo
    nextval('FOO')              comme ci-dessus
    nextval('"Foo"')            opère sur la séquence Foo
    nextval('myschema.foo')     opère sur myschema.foo
    nextval('"myschema".foo')   comme ci-dessus
    nextval('foo')              cherche dans le chemin de parcours des schémas, foo

### Note

Quand vous écrivez l'argument d'une de ces fonctions sous forme de chaîne littérale sans fioritures, il devient une constante de type `regclass` (ou du type approprié). Puisqu'il n'est en fait qu'un OID, l'objet originellement identifié sera tracé même s'il est renommé après, réassigné à un schéma, etc. Cette « liaison précoce » (early binding dans la version originale) est en général désirée pour les références aux objets dans les valeurs par défaut des colonnes et des vues. Mais parfois, une « liaison tardive » (late binding) peut être souhaitée quand la référence à l'objet est résolue à l'exécution. Pour avoir un comportement de liaison tardive, forcez la constante à être stockée en constante `text` au lieu de `regclass` :

    nextval('foo'::text)      foo est interprété au runtime

La fonction `to_regclass()` et ses sœurs peuvent aussi être utilisées pour effectuer des interprétations de paramètres à l'exécution. Voir Tableau 9.70.

Un autre exemple pratique de cas d'usage de `regclass` est de rechercher l'OID d'une table listée dans les vues `information_schema`, qui demandent l'OID de table. En tenant comptes des règles ci-dessus, la façon adéquate de faire cela est

    SELECT table_schema, table_name,
           pg_relation_size((quote_ident(table_schema) || '.' ||
                             quote_ident(table_name))::regclass)
    FROM information_schema.tables
    WHERE ...

La fonction `quote_ident()` gère les identifiants entre guillements quand il y a besoin. La façon suivante qui apparait plus simple

    SELECT pg_relation_size(table_name)
    FROM information_schema.tables
    WHERE ...

n'est pas recommandée, car elle échouera pour les tables en dehors du chemin de parcours des schémas courant ou qui ont un nom qui nécessite des guillemets.

Une propriété supplémentaire de pratiquement tous les types alias d'OID est la création de dépendances. Si une constante d'un de ces types apparaît dans une expression stockée (telle que 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 permet alors pas la suppression de la séquence si l'expression par défaut n'est pas elle-même supprimée au préalable. La version alternative `nextval('ma_seq'::text)` ne crée pas une dépendance. `regrole` est une exception à cette propriété. Les constantes de ce type ne sont pas autorisées dans les expressions enregistrées.

Un autre type d'identifiant utilisé par le système est `xid`, ou identifiant de transaction (abrégée xact). C'est le type de données des colonnes système `xmin` et `xmax`. Les identifiants de transactions sont stockés sur 32 bits. Dans certains contextes, une variante 64-bit `xid8` est utilisée. Contrairement aux valeurs `xid`, les valeurs `xid8` sont strictement à accroissement monotone et ne peuvent être réemployées sur la durée de vie d'une instance de base de données.

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ème `cmin` et `cmax`. Les identifiants de commandes sont aussi stockés sur 32 bits.

Le 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 identifiant de 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ème sont expliquées plus en détail dans la Section 5.5.