Description
CREATE OPERATOR define un nuevo operador, name. El usuario que define el operador se convierte en su propietario.
El operador name es una secuencia de hasta treinta y dos (32) caracteres con cualquiera combinación de lo siguiente:
+ - * / < > = ~ ! @ # % ^ & | ` ? $ :
 | No se permite ningún caracter alfabético en un nombre de operador. Esto permite a Postgres analizar la entrada SQL en elementos sin requerir espacion entre cada elemento. |
El operador "!=" es convertido a "<>" en la entrada, por lo que son en consecuencia equivalentes.
Por lo menos uno de LEFTARG o RIGHTARG deben ser definidos. Para operadores binarios, ambos deberían ser definidos. Para operadores unarios por la derecha, solamente LEFTARG debería ser definido, mientras que en operadores unarios por la derecha solamente RIGHTARG debería ser definido.
También, el procedimiento func_name debe haber sido previamente definido utilizando CREATE FUNCTION y debe se definido para aceptar el número correcto de argumentos (bien uno o dos).
El operador commutador debería ser identificado si existe uno, para que Postgres pudiese invertir el orden de los operandos si lo desea. Por ejemplo, el operador area-menor-que, <<<, debería probablemente tener un operador conmutador area-mayor-que>>>. De esta forma, el optimizador de consultas podría convertir libremente:
"0,0,1,1"::box >>> MYBOXES.description |
MYBOXES.description <<< "0,0,1,1"::box |
Esto permite la ejecución de código para utiliar siempre la última representación y simplifica algo el optimizador.
De forma similar, si existe un operador negador entonces debería ser identificado. Supongamos que un operador, area-igual, ===, existe, y también un operador area-no-igual, !==. El negador permite al optimizador simpificar
NOT MYBOXES.description === "0,0,1,1"::box |
MYBOXES.description !== "0,0,1,1"::box |
Si el nombre de un operador commutador es suministrado, Postgres lo busca en el catálogo. Si es encontrado e no tiene aún un commutador él mismo, entonces la entrada del commutador es actualizada para tener el recien creado operador como su commutador. Esto se aplica al negador, también.
Esto es para permitir la definición de dos operadores que son commutadores de los negadores de cada uno de los otros. El primer operador debería der definido sin un commutador o negador (como sea apropiado). Cuando el segundo operador es definido, se debe nombrar el primero como el commutador o negador. El primero será actualizado como un efecto lateral. (En Postgres 6.5, esto también funciona para simplemente que ambos operadores se refieran al otro).
Los siguientes tres especificadores están presentes para auxiliar al optimizador de consultas al realizar uniones ("joins"). Postgres siempre puede evaluar una unión (i.e., procesando una cláusula con dos variables de tuplas separadas por un operador que retorno un booleano) por substitución iterativa [WONG76]. Además,Postgres es capaz de utilizar un algoritmo "hash-join" siguiendo las líneas de [SHAP86]; sin embargo, debe saber si esta estrategia es aplicable. Es algoritmo "hash-join" actual es solamente correcto para operadores que representan tests de igualdad; además la igualdad del tipo de dato debe significar igualdad a nivel de bits de la representación del tipo. (Por ejemplo, un tipo de dato que contiene bits no utilizados que no tienen repercusión para tests de igualdad podría no ser usado en el "hash-join"). El indicador HASHES indica al optimizador de consultas que un hash join poude ser utilizado de forma segura por este operador.
De forma parecida, los dos operadores de orden indican al optimizador de consultas si la estrategia mezclar-ordenar es utilizable y que operadores deberían ser utilizados para ordenar las clases de los dos operadores. Los operadores de orden deberían ser suministrados solamente para un operador de igualdad, y deberían referirse a operadores menor-que para los tipos de la parte izquierda y derecha respectivamente.
Si otras estrategias de unión son consideradas prácticas, Postgres cambiará el optimizador en tiempo de ejecución para utilizarlas y requerirán especificación adicional cuando un operador sea definido. Afortunadamente, la comunidad investigadora inventa nuevas estrategias de unión infrecuentemente, y la generalidad añadida de estrategias definidas por el usuario no merece la complejidad resultante.
Las dos últimas piezas de la especificación están presentes para que el optimizador pueda estimar los tamaños de los resultados. Si una cláusula de la forma:
MYBOXES.description <<< "0,0,1,1"::box |
Cuando ambos operandos del operador contienen variables de instancia, el optimizador debe estimar el tamaño de la unión resultante. La función join_proc retornara otro numero decimal que será multiplicado por las cardinalidades de las dos clases envueltas en el cómputo del tamaño esperado.
La diferencia entre la función
my_procedure_1 (MYBOXES.description, "0,0,1,1"::box) |
MYBOXES.description === "0,0,1,1"::box |