ALTER OPERATOR FAMILY — Modifier la définition d'une famille d'opérateur
ALTER OPERATOR FAMILYnom
USINGmethode_indexage
ADD { OPERATORnuméro_stratégie
nom_opérateur
(type_op
,type_op
) [ FOR SEARCH | FOR ORDER BYnom_famille_tri
] | FUNCTIONnuméro_support
[ (type_op
[ ,type_op
] ) ]nom_fonction
[ (type_argument
[, ...] ) ] } [, ... ] ALTER OPERATOR FAMILYnom
USINGmethode_indexage
DROP { OPERATORnumero_strategie
(type_op
[ ,type_op
] ) | FUNCTIONnumero_support
(type_op
[ ,type_op
] ) } [, ... ] ALTER OPERATOR FAMILYnom
USINGmethode_indexation
RENAME TOnouveau_nom
ALTER OPERATOR FAMILYnom
USINGmethode_indexation
OWNER TO {nouveau_propriétaire
| CURRENT_ROLE | CURRENT_USER | SESSION_USER } ALTER OPERATOR FAMILYnom
USINGmethode_indexation
SET SCHEMAnouveau_schéma
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 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érateur ; 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é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 36.16 pour plus d'informations.
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érateur 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.
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 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) ;
Il n'existe pas d'instruction ALTER OPERATOR FAMILY
dans
le standard SQL.