ALTER OPERATOR FAMILY — Modifier la définition d'une famille d'opérateur
ALTER OPERATOR CLASS
ALTER OPERATOR FAMILY nom USING methode_indexage ADD
{ OPERATOR numero_strategie nom_operateur ( type_op, type_op )
| FUNCTION numero_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_indexage RENAME TO nouveau_nom
ALTER OPERATOR FAMILY nom USING methode_indexage OWNER TO nouveau_proprietaire
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érateur 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 but 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érateur ; voir CREATE OPERATOR CLASS(7).) PostgreSQL™ la suppression des membres lâches d'une famille à tout moment, mais les membres d'une classe d'opérateur 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 35.14, « Interfacer des extensions d'index » pour plus d'informations.
Le nom d'une famille d'opérateur (pouvant être qualifié du schéma).
Le nom de la méthode d'indexage.
Le numéro de stratégie de la méthode d'indexage pour un opérateur associé avec la famille.
Le nom d'un opérateur (pouvant être qualifié du schéma) associé avec la famille d'opérateur.
Dans une clause OPERATOR, les types de données en opérande de l'opérateur, ou NONE pour signifier un opérateur unaire. 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 index B-tree et hash, il n'est pas strictement nécessaire de spécifier op_type car les types de données en entrée de la fonction sont toujours les bons à utiliser. Pour les index GIN et GiST, 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 supportée doivent être précisés.
Le numéro de la procédure de support de la méthode d'indexage associé avec la famille d'opérateur.
Le nom (pouvant être qualifié du schéma) d'une fonction qui est une procédure de support de la méthode d'indexage pour la famille d'opérateur.
Les types de données pour les arguments de la fonction.
Le nouveau nom de la famille d'opérateur
Le nouveau propriétaire de la famille d'opérateur
Les clauses OPERATOR et FUNCTION peuvent apparaître dans n'importe quel ordre.
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.
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érateur B_tree 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) ;