CREATE OPERATOR

Nom

CREATE OPERATOR — définit un nouvel opérateur utilisateur.
CREATE OPERATOR name (
        PROCEDURE  = func_name
     [, LEFTARG    = type1 ]
     [, RIGHTARG   = type2 ]
     [, COMMUTATOR = com_op ]
     [, NEGATOR    = neg_op ]
     [, RESTRICT   = res_proc ]
     [, JOIN       = join_proc ]
     [, HASHES ]
     [, SORT1      = left_sort_op ]
     [, SORT2      = right_sort_op ]
    )
  

Entrées

name

l'opérateur à définir. Voir plus bas pour les caractères admis.

func_name

fonction utilisée pour implémenter l'opérateur.

type1

le type côté gauche de l'opérateur. Cette option sera omise pour un opérateur unaire droit.

type2

Le type côté droit de l'opérateur. Cette option sera omise pour un opérateur unaire gauche.

com_op

Le commutateur de cet opérateur

neg_op

Le négateur de cet opérateur..

res_proc

La fonction d'estimateur de sélectivité de restriction pour cet opérateur.

join_proc

La fonction d'estimateur de sélectivité de jonction pour cet opérateur.

HASHES

Indique si l'opérateur peut supporter un algorithme de jointure-hachage.

left_sort_op

Opérateur qui trie la donnée type gauche de cet opérateur.

right_sort_op

Opérateur qui trie la donnée type droit de cet opérateur.

Sorties

CREATE

message retourné si l'opérateur a été créé correctement.

Description

CREATE OPERATOR definit un nouvel opérateur, name. L'utilisateur qui définit un opérateur en devient propriétaire.

L'opérateur name est une séquence de plus de 32 caractères dans n'importe quelle combinaison depuis la suivante :

+ - * / < > = ~ ! @ # % ^ & | ` ? $ : 
   

Note

aucun caractère alphabétique n'est admis dans le nom de l'opérateur. Ceci permet à Postgres d'analyser l'entrée SQL dans les mots-clé sans nécessiter d'espace entre chaque mot-clé.

L'opérateur "!=" est mappé vers "<>" en entrée, ainsi il sont donc équivalents.

Enfin un LEFTARG et RIGHTARG doit être défini. Pour les opérateurs binaires, les deux doivent être définis. Pour les opérateurs unaire droit, seulement LEFTARG sera défini, tandis que pour les opérateurs unaire gauche, seulement RIGHTARG sera défini.

Également, la procédure func_name doit avoir été préalablement définie en utilisant CREATE FUNCTION et doit être définie pour accepter le nombre d'arguments correct (un ou deux).

L'opérateur commutateur est présent de façon que Postgres puisse renverser l'ordre des opérandes s'il le désire. Par exemple, l'opérateur area-less-than <<<, aura un opérateur commutateur, area-greater-than, >>>. L'optimiseur de requête pourra librement convertir :
"0,0,1,1"::box  >>> MYBOXES.description
   
en
MYBOXES.description <<< "0,0,1,1"::box
   

Ceci permet au code d'exécution de toujours utiliser la dernière représentation et simplifie l'optimiseur de requête.

De façon similaire, si il existe un opérateur négation, alors il sera identifié. Supposons qu'un opérateur, area-equal, ===, existe, aussi bien que un area not equal, !==. Le lien négation permet à l'optimiseur de requête de simplifier
NOT MYBOXES.description === "0,0,1,1"::box
   
en
MYBOXES.description !== "0,0,1,1"::box
   

Si un nom d'opérateur commutateur est fournit, Postgres le recherche dans le catalogue. Si il est trouvé et qu'il ne peut cependant pas avoir le commutateur lui-même, alors l'entrée commutateur est mise à jour pour avoir l'opérateur courant (nouveau) comme commutateur. Ceci s'applique au négateur aussi bien.

Ceci pour permettre la définition de deux opérateurs que sont les commutateurs ou les négateurs de chaque autre. Le premier opérateur sera défini sans commutateur ou négateur. Quand le second opérateur est défini, nomme le premier comme commutateur ou négateur. Le premier sera mis à jour comme un effet secondaire.

Les trois spécifications suivantes sont présentes pour aider l'optimiseur de requête a exécuter les jointures. Postgres peut toujours évaluer une jointure (i.e., en évaluant une clause avec deux variables tuples séparée par un opérateur qui renvoie un booléen) par substitution itérative [WONG76]. De plus Postgres peut utiliser un algorithme de jointure-hachage dans les lignes de [SHAP86]; cependant, il doit connaître comment appliquer cette stratégie. L'algorithme de jointure-hachage est correct seulement pour les opérateurs qui représentent des tests d'égalité; De plus, l'égalité du datatype doit signifier, au niveau du bit, l'égalité de la représentation du type. (Par exemple, un type de données qui contient des bits non utilisés qui ne servent pas dans les tests d'égalité ne pourrait pas subir de jointure). Le flag HASHES indique à l'optimiseur de requête qu'une jointure de hachage peut de façon sûre être utilisée avec cet opérateur.

De façon similaire, les deux opérateurs de tri indiquent à l'optimiseur de requête comment la fusion-tri utilise la stratégie de jointure et quels opérateurs seront utilisés pour trier les deux classes opérandes. Les opérateurs de tri devront être fournis seulement pour un opérateur d'égalité, et ils se référeront aux opérateurs inférieurs-à pour les données types droite et gauche respectivement.

Si d'autres stratégies de jointures sont ajoutées, Postgres changera l'optimiseur et le système de délai d'exécution pour les utiliser et demandera des spécifications supplémentaires quand un opérateur est défini. Heureusement, la communauté des chercheurs n'invente pas fréquemment de nouvelles stratégies de jointure.

Les deux dernières parties de la spécification sont présentes si l'optimiseur de requête peut estimer les tailles résultant. Si une clause de la forme :
MYBOXES.description <<< "0,0,1,1"::box
   
est présente dans la qualification, alors Postgres devra estimer la partie des instances dans MYBOXES qui satisfont la clause. La fonction res_proc doit être une fonction enregistrée (meaning it is already defined using CREATE FUNCTION) qui accepte les arguments de types donnée corrects et renvoie un nombre décimal. L'optimiseur de requête appelle simplement cette fonction, en passant le paramètre "0,0,1,1" et multiplie le résultat par la taille de la relation pour obtenir le nombre d'instances attendus.

De façon similaire, quand les opérandes de l'opérateur contiennent les deux variables instance, l'optimiseur de requête doit estimer la taille de la jointure résultante. La fonction join-proc retournera un autre nombre décimal qui sera multiplié par les cardinalités des deux classes imbriquées pour calculer la taille des résultats attendus..

La différence entre la fonction
my_procedure_1 (MYBOXES.description, "0,0,1,1"::box)
   
et l'opérateur
MYBOXES.description === "0,0,1,1"::box
   
est que Postgres essaye d'optimiser les opérateurs et peut décider d'utiliser un index pour réduire l'espace de recherche quand les opérateurs sont compliqués. Cependant, il n'y a pas d'essai d'optimiser les fonctions, et elles sont exécutées de façon brutale. De plus, les fonctions peuvent avoir plusieurs arguments tandis que les opérateurs sont limités à un ou deux.

Notes

Voir DROP OPERATOR pour supprimer les opérateurs utilisateur d'une base.

Usage

La commande suivante définit un nouvel opérateur, area-equality, pour le type BOX.

CREATE OPERATOR === (
   LEFTARG = box,
   RIGHTARG = box,
   PROCEDURE = area_equal_procedure,
   COMMUTATOR = ===,
   NEGATOR = !==,
   RESTRICT = area_restriction_procedure,
   JOIN = area_join_procedure,
   HASHES,
   SORT1 = <<<,
   SORT2 = <<<
);
  

Compatibilité

CREATE OPERATOR est une extension Postgres.

SQL92

Il n'existe pas de CREATE OPERATOR en SQL92.