ALTER OPERATOR FAMILY — cambiar la definición de una familia de operadores
ALTER OPERATOR FAMILYnameUSINGindex_methodADD { OPERATORstrategy_numberoperator_name(op_type,op_type) [ FOR SEARCH | FOR ORDER BYsort_family_name] | FUNCTIONsupport_number[ (op_type[ ,op_type] ) ]function_name[ (argument_type[, ...] ) ] } [, ... ] ALTER OPERATOR FAMILYnameUSINGindex_methodDROP { OPERATORstrategy_number(op_type[ ,op_type] ) | FUNCTIONsupport_number(op_type[ ,op_type] ) } [, ... ] ALTER OPERATOR FAMILYnameUSINGindex_methodRENAME TOnew_nameALTER OPERATOR FAMILYnameUSINGindex_methodOWNER TO {new_owner| CURRENT_ROLE | CURRENT_USER | SESSION_USER } ALTER OPERATOR FAMILYnameUSINGindex_methodSET SCHEMAnew_schema
ALTER OPERATOR FAMILY cambia la definición de
una familia de operadores. Puedes agregar operadores y funciones de soporte
a la familia, eliminarlos de la familia, o cambiar el nombre o propietario de la familia.
Cuando se agregan operadores y funciones de soporte a una familia con
ALTER OPERATOR FAMILY, estos no forman parte de ninguna
clase de operadores específica dentro de la familia, sino que simplemente están
“libres” (sueltos) dentro de la familia. Esto indica que estos operadores
y funciones son compatibles con la semántica de la familia, pero no son necesarios
para el correcto funcionamiento de ningún índice específico. (En su lugar, los
operadores y funciones que son obligatorios deben declararse como parte de una clase
de operadores; consulta CREATE OPERATOR CLASS).
PostgreSQL permitirá eliminar miembros libres de una
familia en cualquier momento, pero los miembros de una clase de operadores no se
pueden eliminar sin eliminar toda la clase y cualquier índice que dependa de ella.
Normalmente, los operadores y funciones de un solo tipo de datos forman parte de las
clases de operadores porque son necesarios para admitir un índice en ese tipo de
datos específico, mientras que los operadores y funciones de tipos de datos cruzados
se definen como miembros libres de la familia.
Debes ser superusuario para usar ALTER OPERATOR FAMILY.
(Esta restricción se debe a que una definición errónea de una familia de operadores
podría confundir o incluso hacer caer el servidor).
ALTER OPERATOR FAMILY no verifica actualmente si la definición
de la familia de operadores incluye todos los operadores y funciones requeridos
por el método de índice, ni si los operadores y funciones forman un conjunto
autoconsistente. Es responsabilidad del usuario definir una familia de operadores válida.
Consulta Section 36.16 para obtener más información.
nameEl nombre (opcionalmente calificado por esquema) de una familia de operadores existente.
index_methodEl nombre del método de acceso del índice para el cual sirve esta familia de operadores.
strategy_numberEl número de estrategia del método de acceso del índice para un operador asociado con la familia de operadores.
operator_nameEl nombre (opcionalmente calificado por esquema) de un operador asociado con la familia de operadores.
op_type
En una cláusula OPERATOR, el o los tipos de datos de los
operandos del operador, o bien NONE para indicar un
operador prefijo. A diferencia de la sintaxis comparable en
CREATE OPERATOR CLASS, los tipos de datos de los operandos
siempre deben especificarse.
En una cláusula ADD FUNCTION, el o los tipos de datos de los
operandos que la función está destinada a soportar, si son diferentes del tipo
o tipos de datos de entrada de la función. Para las funciones de comparación de
árbol B (B-tree) y funciones hash, no es necesario especificar op_type ya que los tipos de datos de entrada
de la función siempre son los correctos a usar. Para las funciones de soporte
de ordenación de árbol B, funciones de imagen igual de árbol B, y todas las
funciones en las clases de operadores GiST, SP-GiST y GIN, es necesario especificar
el o los tipos de datos de los operandos con los que se utilizará la función.
En una cláusula DROP FUNCTION, se deben especificar el o los
tipos de datos de los operandos que la función está destinada a soportar.
sort_family_name
El nombre (opcionalmente calificado por esquema) de una familia de operadores
btree existente que describe el orden de ordenación
asociado con un operador de ordenación.
Si no se especifica ni FOR SEARCH ni FOR ORDER BY,
FOR SEARCH es el valor predeterminado.
support_numberEl número de función de soporte del método de acceso del índice para una función asociada con la familia de operadores.
function_nameEl nombre (opcionalmente calificado por esquema) de una función que es una función de soporte del método de acceso del índice para la familia de operadores. Si no se especifica una lista de argumentos, el nombre debe ser único en su esquema.
argument_typeEl o los tipos de datos de los parámetros de la función.
new_nameEl nuevo nombre de la familia de operadores.
new_ownerEl nuevo propietario de la familia de operadores.
new_schemaEl nuevo esquema para la familia de operadores.
Las cláusulas OPERATOR y FUNCTION
pueden aparecer en cualquier orden.
Ten en cuenta que la sintaxis de DROP solo especifica la
“ranura” (slot) en la familia de operadores, mediante el número de
estrategia o de soporte y el o los tipos de datos de entrada. No se menciona
el nombre del operador o función que ocupa la ranura. Además, para DROP
FUNCTION, los tipos a especificar son el o los tipos de datos de
entrada que la función debe soportar; para índices GiST, SP-GiST y GIN, esto
podría no tener nada que ver con los tipos de argumentos de entrada reales
de la función.
Debido a que el mecanismo del índice no verifica los permisos de acceso en las funciones antes de usarlas, incluir una función u operador en una familia de operadores equivale a otorgar un permiso público de ejecución sobre ella. Esto no suele ser un problema para los tipos de funciones que son útiles en una familia de operadores.
Los operadores no deben definirse mediante funciones SQL. Es probable que una función SQL se integre (inline) en la consulta que la llama, lo que evitará que el optimizador reconozca que la consulta coincide con un índice.
El siguiente comando de ejemplo agrega operadores de tipos de datos cruzados y
funciones de soporte a una familia de operadores que ya contiene clases de
operadores de árbol B para los tipos de datos int4 e 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) ;
Para eliminar estas entradas nuevamente:
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) ;
No existe la sentencia ALTER OPERATOR FAMILY en
el estándar SQL.