ALTER DOMAIN — 도메인 정의 바꾸기
ALTER DOMAIN이름{ SET DEFAULT표현식| DROP DEFAULT } ALTER DOMAIN이름{ SET | DROP } NOT NULL ALTER DOMAIN이름ADD도메인_제약조건[ NOT VALID ] ALTER DOMAIN이름DROP CONSTRAINT [ IF EXISTS ]제약조건[ RESTRICT | CASCADE ] ALTER DOMAIN이름RENAME CONSTRAINT제약조건TO새제약조건ALTER DOMAIN이름VALIDATE CONSTRAINT제약조건ALTER DOMAIN이름OWNER TO {새소유주| CURRENT_USER | SESSION_USER } ALTER DOMAIN이름RENAME TO새이름ALTER DOMAIN이름SET SCHEMA새스키마
ALTER DOMAIN 명령은 도메인 정의를 바꾼다.
다음과 같은 여러 구문이 있다:
SET/DROP DEFAULT
도메인 기본값 지정 또는 삭제. 이 값은
INSERT 명령에서만 적용됨을 기억해야 한다;
이미 해당 도멘으로 저장된 자료에 대해서는 아무런 영향을 끼치지 않는다.
SET/DROP NOT NULL
도메인 NULL 값 허용 여부 지정.
해당 도메인이 NULL 값을 허용하지 않고자 할 때,
SET NOT NULL 구문으로 지정한다.
ADD 도메인_제약조건 [ NOT VALID ]
CREATE DOMAIN 명령에서 사용하는 문법과 같은 형태로
해당 도메인에 새 제약 조건을 추가한다.
이렇게 하나의 제약 조건이 추가되면, 그 도메인을 사용하는 모든 칼럼을
대상으로 그 제약 조건에 유효한 값이다 모두 확인한다. 이 유효성
검사 과정을 생략하려면, NOT VALID 옵션을 사용한다;
이렇게 추가한 제약 조건은 나중에,
ALTER DOMAIN ... VALIDATE CONSTRAINT 명령으로
유효성을 검사 할 수 있다.
이 추가 작업 뒤에 발생하는 insert, update 작업에서는
이 제약 조건이 NOT VALID 옵션을 사용해서
만들었다고 하더라도 유효성 검사를 항상 한다.
NOT VALID 옵션은 CHECK 제약 조건에서만
제 역할을 한다.
DROP CONSTRAINT [ IF EXISTS ]
해당 도메인에 지정된 제약 조건을 뺀다.
IF EXISTS 옵션을 사용하면,
해당 제약 조건이 없더라도 오류를 내지 않는다. 이때는 알림
메시지만 보여준다.
RENAME CONSTRAINT제약 조건 이름을 바꾼다.
VALIDATE CONSTRAINT
NOT VALID 옵션으로 만든 제약 조건에 대해서,
실재 모든 자료를 대상으로 그 유효성 검사를 한다.
OWNER해당 도메인의 소유주를 바꾼다.
RENAME해당 도메인의 이름을 바꾼다.
SET SCHEMA해당 스키마를 바꾼다. 도메인에 관련된 모든 제약조건도 함께 새 스키마로 바뀐다.
ALTER DOMAIN 명령은 해당 도메인 소유주만 사용할 수 있다.
스키마를 바꾸는 경우, 소유주는 새 스키마에 대해서
CREATE 권한이 있어야 한다.
소유주를 바꾸는 경우, 기존 소유주는 새 소유주의 소속원이어야 하며,
새 소유주는 해당 도메인의 스키마에 대해 CREATE
권한이 있어야 한다. (새 소유주가 그 도메인을 지우거나,
새로 만들 수 있게 하기 위함이다. 슈퍼유주는 이런 제약 사항을 무시하고
작업 할 수 있다.)
이름작업 대상 도메인 이름(스키마 포함).
도메인_제약조건새 도메인 제약 조건.
제약조건작업할 제약 조건 이름.
NOT VALID기존 자료에 대한 제약 조건 유효성 검사를 하지 않음.
CASCADE해당 제약 조건을 지울 때, 그 제약 조건을 사용하는 모든 개체들도 함께 삭제한다(5.14절 참조).
RESTRICT해당 제약 조건을 지울 때, 그 제약 조건을 사용하는 개체가 하나라도 있으면, 지우지 않는다. 이것은 기본 기능이다.
새이름바뀔 새 도메인 이름.
새제약조건바뀔 새 제약조건 이름.
새소유주해당 도메인의 바뀔 새 소유주 이름.
새스키마해당 도메인의 바뀔 새 스키마 이름.
Although ALTER DOMAIN ADD CONSTRAINT attempts to verify
that existing stored data satisfies the new constraint, this check is not
bulletproof, because the command cannot “see” table rows that
are newly inserted or updated and not yet committed. If there is a hazard
that concurrent operations might insert bad data, the way to proceed is to
add the constraint using the NOT VALID option, commit
that command, wait until all transactions started before that commit have
finished, and then issue ALTER DOMAIN VALIDATE
CONSTRAINT to search for data violating the constraint. This
method is reliable because once the constraint is committed, all new
transactions are guaranteed to enforce it against new values of the domain
type.
현재, ALTER DOMAIN ADD CONSTRAINT, ALTER
DOMAIN VALIDATE CONSTRAINT, ALTER DOMAIN SET NOT NULL
명령은 그 도메인 구성이 복합 자료형인 경우 오류를 낸다.
이런 중첩된 값들에서 사용되는 새 제약조건 검사는
앞으로 개선 되어야 하는 기능이다.
한 도메인에 NOT NULL 제약 조건 추가하는 경우:
ALTER DOMAIN zipcode SET NOT NULL;
NOT NULL 제약 조건을 빼는 경우:
ALTER DOMAIN zipcode DROP NOT NULL;
체크 제약 조건을 추가하는 경우:
ALTER DOMAIN zipcode ADD CONSTRAINT zipchk CHECK (char_length(VALUE) = 5);
체크 제약 조건을 빼는 경우:
ALTER DOMAIN zipcode DROP CONSTRAINT zipchk;
위 체크 제약 조건 이름을 바꾸는 경우:
ALTER DOMAIN zipcode RENAME CONSTRAINT zipchk TO zip_check;
도메인의 스키마를 바꾸는 경우:
ALTER DOMAIN zipcode SET SCHEMA customers;
ALTER DOMAIN 명령은 표준 SQL
구문을 따른다. 단, OWNER, RENAME, SET SCHEMA, VALIDATE CONSTRAINT 옵션은
PostgreSQL 확장 기능이다.
또한 ADD CONSTRAINT 구문에서 NOT VALID
옵션도 PostgreSQL 확장 기능이다.