CREATE OPERATOR

Nombre

CREATE OPERATOR  --  Define un nuevo operador de usuario

Synopsis

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 ] )
  

Entradas

name

El operador a definir. V�anse m�s abajo los caracteres permitidos.

func_name

La funci�n utilizada para implementar este operador.

type1

El tipo de la parte izquierda del operador, si procede. Esta opci�n deber�a ser omitida para un operador unario por la derecha.

type2

El tipo para la parte derecha del operador, si procede. Esta opci�n deber�a ser omitida para un operador unario por la izquierda.

com_op

El commutador para este operador.

neg_op

El negador para este operador.

res_proc

La funci�n estimadora de restricci�n selectiva para este operador.

join_proc

***********The join selectivity estimator function for this operator. ***********La funci�n estimador de ?????

HASHES

Indica que este operador soporta un algoritmo "hash-join".

left_sort_op

Operador que ordena el tipo de dato de la parte izquierda de este operador.

right_sort_op

Operador que ordena el tipo de dato de la parte derecha de este operador.

Salidas

CREATE

Mensaje devuelto si el operador es creado con �xito.

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:

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

Nota

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
   
a
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
   
a
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
   
est� presente in la cualificaci�n, entoncesPostgres puede tener que estimar la fracci�n de instancias en MYBOXES que satisfacen la cl�usula. La funci�n res_proc debe ser una funci�n registrada (lo que significa que ya est� definida utilizando CREATE FUNCTION), acepta argumentos del tipo correcto y devuelve un numero en punto flotante. El optimizador simplemente llama a esta funci�n, pasandole el par�metro "0,0,1,1" y multiplica el resultado por el tama�o de la relaci�n para obtener el deseado numero de instancias estimado.

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)
   
y el operador
MYBOXES.description === "0,0,1,1"::box
   
es quePostgres intenta optimizar operadores y puede decidir utilizar un �ndice para restringir el espacio de b�squeda cuando aparecen operadores. Sin embargo, no se intenta optimizar funciones, y son ejecutadas mediante fuerza bruta. Adem�s, las funciones pueden tener cualquier n�mero de argumentos mientras que los operadores est�n restringidos a uno o dos.

Notes

Refi�rase al cap�tulo sobre operadores en ls PostgreSQL User's Guide para m�s informaci�n. Refi�rase a DROP OPERATOR para borrar operadores definidos por el usuario de una base de datos.

Utilizaci�n Usage

El siguiente comando define un nuevo operador, area-igualdad, para el tipo de dato BOX.

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

Compatibility

SQL92

CREATE OPERATOR is a Postgres extension. There is no CREATE OPERATOR statement in SQL92.