CREATE TABLE

지정되면, 해당 테이블은 임시 테이블로 생성됩니다. 임시 테이블은 세션이 종료될 때, 또는 옵션에 따라 현재 트랜젝션이 끝날 때 (아래 ON COMMIT 참조) 자동으로 drop 됩니다. 같은 이름의 영구적 테이블이 있다면, 스키마-수식명으로 참조하지 않는 한, 임시 테이블이 존재하는 동안은 현재 세션에서 보이지 않습니다. 임시 테이블에 생성된 모든 인덱스 또한 자동으로 임시 객체가 됩니다.

autovacuum daemon은 임시 테이블에 접근할 수 없기 때문에, 임시 테이블에 대한 vacuum이나 analyze를 수행할 수 없습니다. 이러한 이유로, 세션에서 SQL 명령을 통해, 적절한 vacuum과 analyze 작업이 수행되어야 합니다. 예를 들면, 복잡한 쿼리에서 임시 테이블을 사용하려면, 임시 테이블이 증식된 후에 ANALYZE를 수행하는 것이 좋습니다.

선택적으로, TEMPORARY나 TEMP 앞에 GLOBAL 또는 LOCAL을 붙일 수 있습니다. 이는 현재 PostgreSQL에서는 아무런 효과도 없으며, 만료된 기능입니다. Compatibility를 참고하십시오.

지정되면, 해당 테이블이 unlogged 테이블로 생성됩니다. Unlogged 테이블에 기록되는 데이터는 write-ahead 로그 (30장참고)에 기록되지 않으며, 때문에 일반 테이블보다 확연히 빠르게 기록됩니다. 하지만, 이는 사고에 안전하지 않습니다. Unlogged table은 crash 또는 비정상 shutdown 이후에 자동으로 truncate 됩니다. Unlogged table의 내용 또한 standby 서버로 복제되지 않습니다. Unlogged table에 생성된 모든 인덱스도 또한 자동으로 unlogged 상태가 됩니다.

같은 이름의 관계가 이미 있는 경우에 error가 발생하지 않습니다. 대신에 notice가 발생합니다. 기존의 관계가 새로 생성되는 것과 같다는 보장이 없음을 주의하십시오.

생성될 테이블의 (옵션으로 스키마 수식된) 이름.

지정된 복합 (옵션으로 스키마 수식된 이름의) 자료형 구조를 이용한 typed table을 생성합니다. typed table은 자신의 자료형에 묶여 있습니다. 예를 들면, 자료형이 (DROP TYPE ... CASCADE으로) drop되면 테이블도 같이 drop될 것입니다.

Typed 테이블이 생성되면, 해당 열의 데이터 자료형은 CREATE TABLE 명령으로 지정되는 것이 아니라 내재된 복합 자료형에 따라 결정됩니다. 하지만 CREATE TABLE 명령으로 테이블에 기본값과 제약조건을 추가할 수 있고, storage parameter를 지정할 수 있습니다.

신규 테이블에 생성될 열의 이름.

열의 데이터 자료형. 배열 지정자를 포함할 수 있습니다. PostgreSQL에서 지원하는 데이터 자료형에 대한 더 많은 정보는 8장을 참고하십시오.

COLLATE절은 해당 열에 (collate 가능한 데이터 자료형의 열이어야 한다) collation을 할당합니다. 지정하지 않으면, 열 데이터 자료형의 기본 collation이 사용됩니다.

선택적 INHERITS 절은, 신규 테이블이 자동으로 모든 열을 상속받게 될 테이블의 목록을 지정합니다. 상위 테이블은 일반 테이블 또는 참조 테이블을 지정할 수 있습니다.

INHERITS를 사용하면 신규 자식 테이블과 그 부모 테이블 간에 영구적 관계를 생성합니다. 부모의 schema를 변경하면 일반적으로 자식에도 전파되며, 기본적으로 부모(들)를 검색할 때 자식의 데이터가 같이 포함됩니다.

둘 이상의 부모 테이블에 동일한 열 이름이 있다면, 열들의 데이터 자료형이 각 부모 테이블 간에 일치하지 않는 경우 에러가 발생합니다. 출동이 없다면, 중복 열은 새로운 테이블에서 하나의 열로 병합됩니다. 신규 테이블의 열 이름 목록에, 상속받은 열과 동일한 이름이 포함된다면, 해당 데이터 자료형은 상속받은 열의 것과 일치해야 하며, 해당 열의 정의는 하나로 합쳐집니다. 신규 테이블이 명시적으로 열에 대한 기본값을 지정한다면, 이 기본값은 상속받은 열에 선언되어 있던 기본값을 재정의합니다. 명시적으로 지정하지 않은 경우, 해당 열에 기본값을 정의한 부모가 있다면, 모두 동일한 기본값을 지정해야 하며, 그렇지 않으면 에러가 발생합니다.

CHECK 제약은 근본적으로 열과 동일한 방식으로 병합됩니다: 여러 부모 테이블 과/또는 새로운 테이블 정의가, 동일한 이름의 CHECK 제약을 포함하는 경우, 이들 제약은 동일한 check 수식으로 되어 있어야 하며, 그렇지 않으면 에러가 발생합니다. 같은 이름과 수식으로 된 제약조건은 하나로 병합될 것입니다. 부모쪽에서 NO INHERIT으로 표기된 제약조건은 대상이 아닙니다. 신규 테이블의 CHECK 제약에 이름을 지정하지 않은 경우, 항상 고유한 이름이 선택되기 때문에 절대로 병합되지 않습니다.

열의 STORAGE 설정 또한, 부모 테이블에서 복사됩니다.

LIKE 절은, 신규 테이블이 자동으로 모든 열 이름, 데이터 자료형, not-null 제약을 복사해서 가져올 테이블을 지정합니다.

INHERITS와 달리, 생성이 완료된 후에는 신규 테이블과 원본 테이블이 완전히 분리됩니다. 원본 테이블에 대한 변경이 신규 테이블에 적용되지 않으며, 신규 테이블에 포함된 데이터를 원본 테이블에서 검색할 수도 없습니다.

특정 칼럼의 초기값 표현식은 INCLUDING DEFAULTS 구문이 지정된 경우에만 그 초기값 표현식이 복사 된다. 이 구문을 생략하면, 원본 테이블의 초기값 설정은 모두 무시된다. nextval 함수와 같은 데이터베이스 자료 조작 함수가 초기값으로 지정되었다면, 그것도 그대로 지정된다는 점에 주의해야 한다.

Not-null 제약은 항상 신규 테이블로 복사됩니다. INCLUDING CONSTRAINTS가 지정된 경우에만, CHECK 제약이 복사됩니다. 열 제약과 테이블 제약은 따로 구분하지 않습니다.

원본 테이블의 인덱스, PRIMARY KEY, UNIQUE, EXCLUDE 제약조건은 INCLUDING INDEXES 구문을 지정했을 때만 복사된다. 복사해서 새로 만들어지는 각 이름들은 이름 만들기 규칙에 의해서 적당한 이름으로 변경된다. (이 정책은 새로 만들어지는 인덱스의 이름이 같아서 못 만드는 경우를 방지하기 위함이다.)

INCLUDING STORAGE를 지정한 경우에만, STORAGE 설정이 복사되는 열 정의에 복사됩니다. 기본 동작은 STORAGE 설정을 제외하는 것으로, 이 경우 신규 테이블로 복사된 열은 자료형에 따른 기본 설정을 갖게 됩니다. 더 많은 STORAGE 설정 정보는 65.2절를 참고하십시오.

INCLUDING COMMENTS를 지정한 경우에만, 복사되는 열, 제약, 인덱스에 대한 comment가 복사됩니다. 기본 동작은 comment를 제외하는 것으로, 이 경우 신규 테이블로 복사된 열과 제약은 comment가 빠집니다.

INCLUDING ALL은 INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING COMMENTS 의 축약형입니다.

INHERITS와 다르게, LIKE로 복사되는 열과 제약조건은 유사한 이름의 열과 제약끼리 병합되지 않는다는 점도 유의하십시오. 동일한 이름이 명시적으로 지정되거나, 동일한 이름이 다른 LIKE절에 있는 경우, 에러가 발생합니다.

LIKE 절은 뷰, 외래 테이블 또는 복합 자료형 들로부터 열을 복사해 오는 데에도 이용할 수 있습니다. 적용할 수 없는 옵션(예를 들어,뷰로부터의 INCLUDING INDEXES)은 무시됩니다.

선택적인, 열이나 테이블 제약의 이름. 제약조건에 위배되는 경우 해당 제약명이 에러 메시지에 나타나기 때문에, col must be positive와 같은 제약명은, 유용한 제약조건 정보를 클라이언트 응용프로그램에 전달할 수 있습니다. (빈칸이 포함된 제약명을 지정하려면 이중 따옴표가 필요합니다.) 제약명을 지정하지 않으면, 시스템에서 이름을 생성합니다.

해당 열은 null 값을 가질 수 없습니다.

해당 열은 null 값을 가질 수 있습니다. 이게 기본값입니다.

이 절은 단지 비표준 SQL 데이터베이스와의 호환을 위해서 제공됩니다. 신규 응용프로그램에 사용하는 것은 권장하지 않습니다.

CHECK절은, 신규 또는 업데이트되는 행이 삽입 또는 업데이트 동작을 성공적으로 수행하기 위해 충족해야 하는, Boolean 결과를 생성하는 수식을 지정합니다. TRUE 또는 UNKNOWN으로 계산되는 수식은 성공입니다. 결과로 FALSE 생성하는 열 삽입이나 업데이트 작업은 에러 예외가 발생하며, 해당 작업은 데이터베이스에 영향을 주지 않습니다. 열 제약으로 지정된 Check 제약은 해당 열의 값만 참조해야 하며, 테이블 제약의 수식은 여러 열을 참조할 수 있습니다.

현재, CHECK 수식은 서브쿼리를 포함할 수 없으며, 현재 행의 열이 아닌 것의 값을 참조할 수도 없습니다.

NO INHERIT로 표기된 제약은 자식 테이블에 전파되지 않습니다.

When a table has multiple CHECK constraints, they will be tested for each row in alphabetical order by name, after checking NOT NULL constraints. (PostgreSQL versions before 9.5 did not honor any particular firing order for CHECK constraints.)

DEFAULT 절은 이를 정의에 포함하는 열에 대한 기본값을 할당합니다. 해당 값은 변하지 않는 어떠한 수식이라도 됩니다. (서브쿼리나 현재 테이블의 다른 열에 대한 상호 참조는 허용되지 않습니다.) 기본값 수식의 데이터 자료형은 해당 열의 데이터 자료형과 일치해야 합니다.

기본값 수식은 해당 열의 값을 지정하지 않은 모든 삽입 작업에 사용될 것입니다. 열에 기본값이 없는 경우, null이 기본값이 됩니다.

UNIQUE 제약은 테이블 내에서 고유값만 포함할 수 있는 하나 이상의 열 그룹을 지정합니다. Unique 테이블 제약의 동작은 unique 열 제약과 동일하나, 여러 열을 포함할 수 있게 됩니다.

Unique 제약의 목적에 맞게, null 값은 서로 다른 것으로 간주됩니다.

각 unique 테이블 제약에서 지정한 열 집합은, 다른 unique나 primary key 제약에서 지정한 열 집합과 달라야 합니다. (그렇지 않으면, 단지 같은 제약이 두 번 나열될 뿐입니다.)

The PRIMARY KEY constraint specifies that a column or columns of a table can contain only unique (non-duplicate), nonnull values. Only one primary key can be specified for a table, whether as a column constraint or a table constraint.

The primary key constraint should name a set of columns that is different from the set of columns named by any unique constraint defined for the same table. (Otherwise, the unique constraint is redundant and will be discarded.)

PRIMARY KEY enforces the same data constraints as a combination of UNIQUE and NOT NULL, but identifying a set of columns as the primary key also provides metadata about the design of the schema, since a primary key implies that other tables can rely on this set of columns as a unique identifier for rows.

EXCLUDE 절은, 임의의 두 행이 지정된 열 또는 지정된 연산자를 이용하는 수식으로 서로 비교되는 경우, 비교 결과가 모두 TRUE가 되지 않도록 보장하는, exclusion 제약을 정의합니다. 지정된 연산자가 모두 동등 비교를 한다면, 이는 UNIQUE 제약과 동일합니다, 물론 보통의 unqiue 제약이 더 빠를 것입니다. 하지만, exclusion 제약은 단순한 동등 비교보다 더 포괄적으로 제약을 지정할 수 있습니다. 예를 들어, && 연산자를 이용하면, 테이블의 어떠한 두 행도 서로 겹쳐지는 원8.8절 참고)을 포함하지 못하도록 제약을 지정할 수 있습니다.

Exclusion 제약은 인덱스를 이용하여 구현되며, 때문에 각 지정 연산자는 인덱스 접근 메서드 index_method와 맞는 적절한 연산자 클래스(11.9절 참고)와 연결되어야 합니다. 해당 연산자는 각 항의 나열순서에 관계없이 결과가 동일해야 합니다. 각 exclude_element는 선택적으로 연산자 클래스 와/또는 정렬 옵션을 지정할 수 있습니다. 이에 대해서는 CREATE INDEX에서 모두 설명됩니다.

해당 접근 메서드는 amgettuple(59장 참고)를 지원해야 합니다. 현재 이는 GIN이 사용될 수 없다는 것을 의미합니다. 설령 허용된다 해도, exclusion 제약에 B-tree나 hash 인덱스를 사용하는 것은 별로 의미가 없습니다. 일반 unique 제약보다 나을게 아무것도 없기 때문입니다. 때문에, 실질적으로 접근 메서드는 항상 GiST거나 SP-GiST가 됩니다.

predicate는 테이블의 서브셋에 exclusion 제약을 지정하는 것을 허용합니다. 이것은 내부적으로 부분 인덱스를 생성합니다. 해당 predicate를 괄호로 감싸야 한다는 점에 주의하십시오.

이 절은, 신규 테이블의 하나 이상의 열 그룹이, 참조되는 테이블의 행에 있는 열(들)의 값과 일치하도록 요구하는, 외래키 제약을 지정합니다. refcolumn이 생략되면, reftable의 primary key가 사용됩니다. 참조되는 열은 참조되는 테이블의 non-deferrable unique나 primary key 제약의 열이어야 합니다. 외래키 제약은 임시 테이블과 영구적 테이블 간에 정의할 수 없다는 점을 유의하십시오.

지정된 일치 조건을 이용하여, 참조하는 열(들)에 삽입되는 값이 참조되는 테이블과 참조되는 열의 값에 대응됩니다. 다음의 세가지 일치 조건: MATCH FULL, MATCH PARTIAL, 그리고 기본값인 MATCH SIMPLE이 있습니다. MATCH FULL은 외래키의 모든 열이 null인 경우를 제외하고, 다중열 외래키의 한개 열이 null이 되는 것을 허용하지 않을 것입니다. 모두 null인 경우, 해당 행은 참조되는 테이블의 것과 일치되지 않아도 됩니다. MATCH SIMPLE은 외래키의 일부 열이 null이 되는 것을 허용합니다. 어떤 열이든 null이 있으면, 해당 행은 참조되는 테이블의 것과 일치되지 않아도 됩니다. MATCH PARTIAL은 아직 구현되지 않았습니다. (물론, 이런 일이 일어나는 것을 방지하기 위해, NOT NULL 제약을 참조하는 열(들)에 적용할 수 있습니다.)

추가로, 참조되는 열의 데이터가 변경될 때, 이 테이블의 열 데이터에 특정 작업이 수행됩니다. ON DELETE 절은 참조되는 테이블의 참조되는 행이 삭제될 때에 수행될 작업을 지정합니다. 마찬가지로, ON UPDATE 절은 참조되는 테이블의 참조되는 열이 새로운 값으로 업데이트 될 때에 수행될 작업을 지정합니다. 해당 행이 업데이트 되었지만, 실제론 참조되는 열에 변경점이 없다면, 아무런 작업도 수행되지 않습니다. 제약이 deferred로 선언되었더라도, NO ACTION을 제외한 참조 작업은 deferred가 될 수 없습니다. 다음은 각 절에 가능한 작업입니다:

참조되는 열(들)이 자주 변경되는 경우, 외래키 제약과 관련된 참조동작이 좀더 효율적으로 수행될 수 있도록, 외래키 열에 인덱스를 추가하는 것이 좋습니다.

이는 제약조건이 연기될 수 있는지 여부를 제어합니다. Deferrable이 아닌 제약조건은 매 명령 직후에 검사될 것입니다. (SET CONSTRAINTS 명령을 사용헤서) Deferrable인 제약조건은 트랜잭션이 끝날 때까지 검사를 연기합니다. NOT DEFERRABLE이 기본값입니다. 현재, UNIQUE, PRIMARY KEY, EXCLUDE 및 REFERENCES(외래키) 제약에만 이 절을 입력할 수 있습니다. NOT NULL 및 CHECK 제약은 deferrable이 될 수 없습니다. Note that deferrable constraints cannot be used as conflict arbitrators in an INSERT statement that includes an ON CONFLICT DO UPDATE clause.

제약조건이 deferrable이면, 이 절은 제약을 검사하는 기본 시점을지정합니다. 제약조건이 INITIALLY IMMEDIATE이면, 매 문장 뒤에 검사됩니다. 이것이 기본값입니다. 제약조건이 INITIALLY DEFERRED이면, 트랜잭션의 마지막에만 검사됩니다. 제약 검사시점은 SET CONSTRAINTS 명령으로 변경할 수 있습니다.

이절은 테이블이나 인덱스에 대한 선택적 storage parameter를 지정합니다. 더 많은 정보는 Storage Parameters를 참고하십시오. 또한, 테이블에 대한 WITH 절은, 신규 테이블의 행이 OID(개체 식별자)를 갖도록 지정하는 OIDS=TRUE (또는 그냥 OIDS)나 행이 OID를 가질수 없도록 지정하는 OIDS=FALSE를 포함할 수 있습니다. OIDS가 지정되지 않으면, 기본 설정은 default_with_oids 구성 파라미터를 따라갑니다. (신규 테이블이 OID를 갖는 테이블을 상속받는 경우, OIDS=FALSE라고 명령을 내려도 강제로 OID=TRUE가 됩니다.)

OIDS=FALSE가 지정되거나 암시되면, 신규 테이블은 OID를 저장하지 않으며, 해당 테이블에 새로 추가되는 행에도 OID가 할당되지 않게 됩니다. 이는 보통 유용한데, OID 소비를 줄이며 32비트 OID 카운터의 꺾어짐(wrap-around)을 지연시키기 때문입니다. 카운터가 한번 꺾어지면, OID는 더 이상 고유하지 않게되어, 유용성이 상당히 떨어지게 됩니다. 또한, 테이블에서 OID를 제거하면 디스크에 해당 테이블을 저장하기 위한 공간이, 매 행마다 (대부분의 장치에서)4바이트씩 줄어들며, 성능 향상에 약간의 도움이 됩니다.

테이블이 생성된 이후 OID를 제거하려면, ALTER TABLE을이용하십시오.

각각, WITH (OIDS) 및 WITH (OIDS=FALSE)와 동일한 구식 문법입니다. 만약, OIDS 설정과 storage parameter를 동시에 지정하고 싶다면, 위의 WITH ( ... )구문을 사용해야 합니다. 위를 참고하십시오.

ON COMMIT을 이용하여, 트랜잭션 블록의 마지막에 임시 테이블의 동작 방식을 제어할 수 있습니다. 다음에 3가지 옵션이 있습니다:

tablespace_name은 신규 테이블이 생성될 tablespace의 이름입니다. 지정하지 않으면 default_tablespace이 제시되며, 임시 테이블인 경우엔 temp_tablespaces이 됩니다.

이 절은 UNIQUE, PRIMARY KEY, 또는 EXCLUDE 제약과 연관된 인덱스가 생성될 테이블스페이스를 선택할 수 있게 합니다. 지정하지 않으면 default_tablespace가 제시되며, 임시 테이블인 경우엔 temp_tablespaces가 됩니다.