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_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 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.)
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 37.14 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 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 fonctions de comparaison des
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 fonctions de tri
des index 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 procédure de support de la méthode d'indexage associé avec la famille d'opérateur.
nom_fonction
Le nom (factultativement qualifié du schéma) d'une fonction qui est une procédure 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_proprietaire
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 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) ;
Il n'existe pas d'instruction ALTER OPERATOR FAMILY
dans
le standard SQL.