Description
CREATE OPERATOR définit un nouvel opérateur name. L'utilisateur qui crée l'opérateur en devient le propriétaire.
The operator name est une séquence supérieure à NAMEDATALEN-1 (31 par défaut) caractères de la liste suivante :
+ - * / < > = ~ ! @ # % ^ & | ` ? $
$ ne peut être défini comme caractère opérateur unique, bien qu'il puisse faire partie d'un nom d'opérateur multicaractères.
-- et /* ne peuvent apparaître nulle part dans un nom d'opérateur, car ils sont pris comme le début d'un commentaire.
Un nom d'opérateur multicaractères ne peut finir avec + ou -, à moins que le nom ne contienne aussi au moins un des ces caractères :
~ ! @ # % ^ & | ` ? $
Par exemple, @- est un nom d'opérateur admis, mais *- ne l'est pas. Cette restriction permet à PostgreSQL d'analyser les requêtes conformes au SQL sans avoir besoin d'espaces entre les signes.
 | Quand vous travaillez avec des noms d'opérateur non-standards SQL, vous avez besoin habituellement de séparer les opérateurs adjacents avec des espaces pour éviter toute ambiguïté. Par exemple, si vous avez défini un opérateur unaire-gauche nommé @, vous ne pourrez écrire X*@Y; vous devez simplement écrire X* @Y pour vous assurer que PostgreSQL les lit comme deux noms d'opérateurs pas un. |
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 :
box '((0,0), (1,1))' >>> MYBOXES.description |
MYBOXES.description <<< box '((0,0), (1,1))' |
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 === box '((0,0), (1,1))' |
MYBOXES.description !== box '((0,0), (1,1))' |
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 options HASHES, SORT1, et SORT2 sont présentes pour aider l'optimiseur de requête a exécuter les jointures. PostgreSQL peut toujours évaluer une jointure (i.e., en évaluant une clause avec deux variables de tuples séparées 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 type doit signifier, au niveau du bit, l'égalité de la représentation du type. (Par exemple, un type 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 options RESTRICT et JOIN aident l'optimiseur de requête dans l'estimation des tailles de résultats? Si une clause de la forme :
MYBOXES.description <<< box '((0,0), (1,1))' |
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, box '((0,0), (1,1))') |
MYBOXES.description === box '((0,0), (1,1))' |