Documentation PostgreSQL 15.15 » Référence » Commandes SQL » ALTER OPERATOR FAMILY

Précédent | Niveau supérieur | Suivant
ALTER OPERATOR CLASS | Sommaire | ALTER POLICY

## ALTER OPERATOR FAMILY

ALTER OPERATOR FAMILY — Modifier la définition d'une famille d'opérateur

## Synopsis

    ALTER OPERATOR FAMILY nom USING methode_indexage ADD
      {  OPERATOR numéro_stratégie nom_opérateur ( type_op, type_op )
                  [ FOR SEARCH | FOR ORDER BY nom_famille_tri ]
       | FUNCTION numéro_support [ ( type_op [ , type_op ] ) ]
                  nom_fonction [ ( type_argument [, ...] ) ]
      } [, ... ]
    ALTER OPERATOR FAMILY nom USING methode_indexage DROP
      {  OPERATOR numero_strategie ( type_op [ , type_op ] )
       | FUNCTION numero_support ( type_op [ , type_op ] )
      } [, ... ]

    ALTER OPERATOR FAMILY nom USING methode_indexation
        RENAME TO nouveau_nom

    ALTER OPERATOR FAMILY nom USING methode_indexation
        OWNER TO { nouveau_propriétaire | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

    ALTER OPERATOR FAMILY nom USING methode_indexation
        SET SCHEMA nouveau_schéma

## Description

`ALTER OPERATOR FAMILY` modifie la définition d'une famille d'opérateur. Vous pouvez ajouter des opérateurs et des fonctions du support à la famille, les supprimer ou modifier le nom et le propriétaire de la famille.

Quand les opérateurs et fonctions de support sont ajoutés à une famille avec la commande `ALTER OPERATOR FAMILY`, ils ne font partie d'aucune classe d'opérateurs spécifique à l'intérieur de la famille. Ils sont « lâches » dans la famille. Ceci indique que ces opérateurs et fonctions sont compatibles avec la sémantique de la famille mais qu'ils ne sont pas requis pour un fonctionnement correct d'un index spécifique. (Les opérateurs et fonctions qui sont ainsi nécessaires doivent être déclarés comme faisant partie d'une classe d'opérateurs ; voir CREATE OPERATOR CLASS.) PostgreSQL autorise la suppression des membres lâches d'une famille à tout moment, mais les membres d'une classe d'opérateurs ne peuvent pas être supprimés sans supprimer toute la classe et les index qui en dépendent. Typiquement, les opérateurs et fonctions sur un seul type de données font partie des classes d'opérateurs car ils ont besoin de supporter un index sur ce type de données spécifique alors que les opérateurs et familles inter-types sont fait de membres lâches de la famille.

Vous devez être superutilisateur pour utiliser `ALTER OPERATOR FAMILY`. (Cette restriction est faite parce qu'une définition erronée d'une famille d'opérateur pourrait gêner, voire même arrêter brutalement le serveur.)

`ALTER OPERATOR FAMILY` ne vérifie pas encore si la définition de l'opérateur de famille inclut tous les opérateurs et fonctions requis par la méthode d'indexage, ni si les opérateurs et les fonctions forment un ensemble cohérent et suffisant. C'est de la responsabilité de l'utilisateur de définir une famille d'opérateur valide.

Voir Section 38.16 pour plus d'informations.

## Paramètres

`nom`

  Le nom d'une famille d'opérateur (pouvant être qualifié du schéma).

`methode_indexage`

  Le nom de la méthode d'indexage.

`numero_strategie`

  Le numéro de stratégie de la méthode d'indexage pour un opérateur associé avec la famille.

`nom_operateur`

  Le nom d'un opérateur (pouvant être qualifié du schéma) associé avec la famille d'opérateur.

`type_op`

  Dans une clause `OPERATOR`, les types de données en opérande de l'opérateur, ou `NONE` pour signifier un opérateur préfixe. Contrairement à la syntaxe comparable de `CREATE OPERATOR CLASS`, les types de données en opérande doivent toujours être précisés.

  Dans une clause `ADD FUNCTION`, les types de données des opérandes que la fonction est sensée supporter, si différent des types de données en entrée de la fonction. Pour les fonctions de comparaison des index B-tree et hash, il n'est pas strictement nécessaire de spécifier `type_op` car les types de données en entrée de la fonction sont toujours les bons à utiliser. Pour les fonctions de tri des index B-tree, les fonctions d'égalité d'image B-Tree, ainsi que pour toutes les fonctions des classes d'opérateurs GIST, SP-GiST et GIN, il est nécessaire de spécifier le type de données en entrée qui sera utilisé par la fonction.

  Dans une clause `DROP FUNCTION`, les types de données en opérande que la fonction est sensée supporter doivent être précisés. Pour les index GiST, SP-GiST et GIN, les types en question pourraient ne pas être identiques aux des arguments en entrée de la fonction.

`nom_famille_tri`

  Le nom d'une famille d'opérateur `btree` (pouvant être qualifié du schéma) décrivant l'ordre de tri associé à l'opérateur de tri.

  Si ni `FOR SEARCH` ni `FOR ORDER BY` ne sont indiqués, `FOR SEARCH` est la valeur par défaut.

`numero_support`

  Le numéro de la fonction de support de la méthode d'indexage associé avec la famille d'opérateur.

`nom_fonction`

  Le nom (en option qualifié du schéma) d'une fonction qui est une fonction de support d'une méthode d'index pour la famille d'opérateur. Si aucune liste d'argument n'est spécifiée, le nom doit être unique dans son schéma.

`argument_types`

  Les types de données pour les arguments de la fonction.

`nouveau_nom`

  Le nouveau nom de la famille d'opérateur

`nouveau_propriétaire`

  Le nouveau propriétaire de la famille d'opérateur

`nouveau_schéma`

  Le nouveau schéma de la famille d'opérateur.

Les clauses `OPERATOR` et `FUNCTION` peuvent apparaître dans n'importe quel ordre.

## Notes

Notez que la syntaxe `DROP` spécifie uniquement le « slot » dans la famille d'opérateur, par stratégie ou numéro de support et types de données en entrée. Le nom de l'opérateur ou de la fonction occupant le slot n'est pas mentionné. De plus, pour `DROP FUNCTION`, les types à spécifier sont les types de données en entrée que la fonction doit supporter ; pour les index GIN et GiST, ceci pourrait ne rien avoir à faire avec les types d'argument en entrée de la fonction.

Comme le processus des index ne vérifie pas les droits sur les fonctions avant de les utiliser, inclure une fonction ou un opérateur dans une famille d'opérateur est équivalent à donner le droit d'exécution à public. Ceci n'est généralement pas un problème pour les tris de fonction qui sont utiles à une famille d'opérateur.

Les opérateurs ne doivent pas être définis par des fonctions SQL. Une fonction SQL risque d'être remplacée dans la requête appelante, ce qui empêchera l'optimiseur de savoir si la requête peut utiliser un index.

Avant PostgreSQL 8.4, la clause `OPERATOR` pouvait inclure une option `RECHECK`. Ce n'est plus supporté parce que le fait qu'un opérateur d'index soit « à perte » est maintenant déterminé à l'exécution. Cela permet une gestion plus efficace des cas où un opérateur pourrait ou non être à perte.

## Exemples

La commande exemple suivant ajoute des opérateurs inter-type de données et ajoute les fonctions de support pour une famille d'opérateur qui contient déjà les classes d'opérateurs Btree pour les types de données `int4` et `int2`.

    ALTER OPERATOR FAMILY integer_ops USING btree ADD

      -- int4 vs int2
      OPERATOR 1 < (int4, int2) ,
      OPERATOR 2 <= (int4, int2) ,
      OPERATOR 3 = (int4, int2) ,
      OPERATOR 4 >= (int4, int2) ,
      OPERATOR 5 > (int4, int2) ,
      FUNCTION 1 btint42cmp(int4, int2) ,

      -- int2 vs int4
      OPERATOR 1 < (int2, int4) ,
      OPERATOR 2 <= (int2, int4) ,
      OPERATOR 3 = (int2, int4) ,
      OPERATOR 4 >= (int2, int4) ,
      OPERATOR 5 > (int2, int4) ,
      FUNCTION 1 btint24cmp(int2, int4) ;

Pour supprimer de nouveau ces entrées :

    ALTER OPERATOR FAMILY integer_ops USING btree DROP

      -- int4 vs int2
      OPERATOR 1 (int4, int2) ,
      OPERATOR 2 (int4, int2) ,
      OPERATOR 3 (int4, int2) ,
      OPERATOR 4 (int4, int2) ,
      OPERATOR 5 (int4, int2) ,
      FUNCTION 1 (int4, int2) ,

      -- int2 vs int4
      OPERATOR 1 (int2, int4) ,
      OPERATOR 2 (int2, int4) ,
      OPERATOR 3 (int2, int4) ,
      OPERATOR 4 (int2, int4) ,
      OPERATOR 5 (int2, int4) ,
      FUNCTION 1 (int2, int4) ;

## Compatibilité

Il n'existe pas d'instruction `ALTER OPERATOR FAMILY` dans le standard SQL.

## Voir aussi

CREATE OPERATOR FAMILY, DROP OPERATOR FAMILY, CREATE OPERATOR CLASS, ALTER OPERATOR CLASS, DROP OPERATOR CLASS