ALTER OPERATOR FAMILY — 연산자 가족 정의 바꾸기
ALTER OPERATOR FAMILY이름USING색인방법ADD { OPERATOR전략번호연산자(연산자자료형,연산자자료형) [ FOR SEARCH | FOR ORDER BYsort_family_name] | FUNCTION지원번호[ (연산자자료형[ ,연산자자료형] ) ]함수이름[ (인자자료형[, ...] ) ] } [, ... ] ALTER OPERATOR FAMILY이름USING색인방법DROP { OPERATOR전략번호(연산자자료형[ ,연산자자료형] ) | FUNCTION지원번호(연산자자료형[ ,연산자자료형] ) } [, ... ] ALTER OPERATOR FAMILY이름USING색인방법RENAME TO새이름ALTER OPERATOR FAMILY이름USING색인방법OWNER TO {새소유주| CURRENT_USER | SESSION_USER } ALTER OPERATOR FAMILY이름USING색인방법SET SCHEMA새스키마
ALTER OPERATOR FAMILY 명령은
연산자 가족 정의를 바꾼다.
해당 연산자 가족에 연산자나 지원 함수를 추가하거나 뺄 수 있으며,
그 이름이나, 소유주를 바꾼다.
ALTER OPERATOR FAMILY 명령을 이용해서
연산자 가족에 연산자나 지원 함수를 추가하면, 그 가족에 속한
특정 연산자 클래스에 속하지는 않는다. 이를 “느슨한”
구성이라 한다. 즉, 이 연산자와 함수들이 해당 가족이라는
의미는 있지만, 특정 인덱스에서 이 연산자들과 함수들을
바르게 사용한다는 보장은 없다. (이것을 원한다면,
그 연산자와 함수를 연산자 클래스로 정의해야 한다.
CREATE OPERATOR CLASS 참조)
PostgreSQL에서는
이런 느슨하게 구성된 구성원들(연산자, 함수)은 그 가족에서
언제든지 삭제할 수 있지만, 연산자 클래스의 구성원이 되면,
그 연산자 클래스를 사용하는 인덱스가 있는 한 구성원에서
빠질 수 없다.
보통 단일 자료형에 대한 연산자와 함수 처리를 위해서는
연산자 클래스로 정의해서 사용하고,
서로 다른 자료형에 대한 연산자와 함수 처리를 위해서는
연산자 가족으로 정의한다.
ALTER OPERATOR FAMILY 명령은 슈퍼유저 전용이다.
(이 작업은 잘못 작업하면 서버가 중지될 수도 있기 때문에, 엄격하게
제한 한다.)
ALTER OPERATOR FAMILY 명령은
색인 방법에서 필요한 모든 연산자와 함수가 연산자 가족에 포함되었는지
확인하지 않는다. 또한 연산자와 함수가 일관성 있는 집합인지도
확인하지 않는다. 올바른 연산자 가족을 만드는 책임은 사용자에게 있다.
더 자세한 정보는 37.16절에서 다룬다.
이름작업 대상 연산자 가족 이름(스키마 이름 포함).
색인방법해당 연산자 가족이 사용하는 색인 방법(접근 방법).
전략번호작업 대상 연산자의 연산자 가족 내 전략 번호.
연산자연산자 가족 구성 연산자 이름(스키마 이름을 포함)
연산자자료형
OPERATOR 옵션에서 사용하는 해당 연산자의
왼쪽 오른쪽 자료형. 단항 연산자면, 없는 쪽은 NONE.
CREATE OPERATOR CLASS 명령과 달리 여기서는 반드시
자료형을 지정해야 한다.
ADD FUNCTION 옵션에서
그 함수의 입력 인자 자료형과 다른 반환 자료형을 사용한다면,
그 자료형을 연산자 자료형으로 지정한다.
B-tree 비교 함수와 해시 함수는 항상 일정한 값을 사용하기 때문에,
연산자자료형을
지정할 필요는 없다. 반면, B-tree 정렬 함수, B-tree 동등 이미지 함수,
GiST, SP-SiST, GIN 연산자 클래스인 경우는 이 연산자 자료형을 지정한다.
DROP FUNCTION 옵션에서는 그 함수를 식별할 필요가
있는 경우 적당한 연산자 자료형을 지정해서 사용한다.
sort_family_name
정렬 연산과 관련된 작업을 지정한
이미 있는 btree 연산자 가족 이름(스키마 이름 포함).
FOR SEARCH, FOR ORDER BY 두 예약어 모두
사용하지 않았다면, FOR SEARCH 로 간주한다.
지원번호해당 연산자 가족의 구성원으로써 사용하는 함수의 색인 방법의 지원 번호.
함수이름해당 연산자 가족 구성원 함수 이름(스키마 이름 포함). 인자 목록이 빠지면 그 함수는 해당 스키마 안에 하나만 있어야 한다.
인자자료형해당 함수 입력 매개 변수 자료형.
새이름바뀔 새 연산자 가족 이름.
새소유주바뀔 새 소유주.
새스키마바뀔 새 스키마 이름.
OPERATOR , FUNCTION
순서는 상관 없다.
연산자 가족에서
DROP 작업은 해당 연산자의 전략 번호나 함수의 지원 번호와
그 연산자 자료형을 지정해서 진행됨을 기억해야 한다.
연산자나 함수의 이름을 지정해서 지우지 않는다. 또한
DROP FUNCTION 작업인 경우는 그 함수의 연산자 자료형을
지정한다. GiST, SP-GiST, GIN 인덱스 용 연산자 가족인 경우는
함수의 입력 인자 자료형은 아무런 영향을 주지 않는다.
연산자 가족 구성원인 함수나 연산자는 일반적으로 누구나 사용할 수 있는 권한을 부여한다. 왜냐하면, 이들은 실재 인덱스 작업을 하기 전까지는 권한 검사를 하지 않기 때문이다. 이런 권한 정책은 일반적인 환경에서는 크게 문제가 되지 않는다.
연산자는 SQL 함수로 정의하지 말아야한다. SQL 함수는 쿼리가 실행 될 때 다시 처리해서 하나의 새로운 쿼리로 실행되기 때문이다. (SQL 함수의 인라인 처리에 대한 이야기다 - 옮긴이) 이렇게 되면, 쿼리 최적화기가 그 쿼리에서 어떻게 인덱스를 사용해야 할지 모르는 경우가 발생한다.
PostgreSQL 8.4 버전까지는 OPERATOR
구문에 RECHECK 옵션이 있었다. 이제는
이 검사 기능을 쿼리가 실행 될 때마다 항상 사용하기에 이제는 지원하지 않는다.
This allows efficient handling of
cases where an operator might or might not be lossy.
아래 예제는 int4, 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) ;
다시 원래 대로:
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) ;
ALTER OPERATOR FAMILY 구문은 표준 SQL 구문이 아니다.