| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE
table_name
( [
{
column_name
data_type
[ DEFAULT
default_expr
] [
column_constraint
[ ... ] ]
|
table_constraint
| LIKE
parent_table
[ { INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES } ] ... }
[, ... ]
] )
[ INHERITS (
parent_table
[, ... ] ) ]
[ WITH (
storage_parameter
[=
value
] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE
tablespace
]
column_constraint
에는, 다음의 구문이 들어갑니다.
[ CONSTRAINT
constraint_name
]
{ NOT NULL |
NULL |
UNIQUE
index_parameters
|
PRIMARY KEY
index_parameters
|
CHECK (
expression
) |
REFERENCES
reftable
[ (
refcolumn
) ] [ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
[ ON DELETE
action
] [ ON UPDATE
action
] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
또,
table_constraint
에는, 다음의 구문이 들어갑니다.
[ CONSTRAINT
constraint_name
]
{ UNIQUE (
column_name
[, ... ] )
index_parameters
|
PRIMARY KEY (
column_name
[, ... ] )
index_parameters
|
CHECK (
expression
) |
FOREIGN KEY (
column_name
[, ... ] ) REFERENCES
reftable
[ (
refcolumn
[, ... ] ) ]
[ MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ] [ ON DELETE
action
] [ ON UPDATE
action
] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY IMMEDIATE ]
UNIQUE및PRIMARY KEY제약내의
index_parameters
는 이하와 같습니다.
[ WITH (
storage_parameter
[=
value
] [, ... ] ) ]
[ USING INDEX TABLESPACE
tablespace
]
CREATE TABLE는, 현재의 데이타베이스에 새로운 하늘의 테이블을 작성합니다. 작성한 테이블은 이 커멘드를 실행한 유저가 소유합니다.
schema명을 붙일 수 있고 있는 경우(예를 들면,CREATE TABLE myschema.mytable ...), 테이블은 지정된 schema로 작성됩니다. schema명이 없으면, 테이블은 현재의 schema로 작성됩니다. 또, 일시 테이블은 특별한 schema에 존재하기 위해(때문에), 일시 테이블의 작성시에 schema명을 줄 수 없습니다. 테이블명은, 같은 schema내의 다른 테이블, 순서, 인덱스, 뷰와는 다른 이름으로 할 필요가 있습니다.
게다가CREATE TABLE는, 작성하는 테이블의 1행에 대응하는 복합형의 데이터형을 작성합니다. 따라서, 테이블은, 같은 schema내의 기존의 데이터형과 같은 이름을 가질 수가 없습니다.
제약구에는, 삽입, 갱신 조작을 실시하기 위해서(때문에), 새로운 행, 또는 갱신하는 행이 채우지 않으면 안 되는 제약(검사 항목)을 지정합니다. 제약구는 생략 가능합니다. 제약은, 테이블내에서 여러가지 유효한 값의 집합을 정의할 때, 도움이 되는 SQL 오브젝트입니다.
제약의 정의에는 테이블 제약과 열제약이라고 하는 2 종류가 있습니다. 열제약은 열정의의 일부로서 정의됩니다. 테이블 제약 정의는, 특정의 열과는 묶을 수 있지 않고, 복수의 열을 함유 할 수가 있습니다. 또, 모든 열제약은 테이블 제약으로서 기술할 수가 있습니다. 열제약은, 1개의 열에게만 영향을 주는 제약을 위한, 간편한 기술 방법으로 지나지 않습니다.
이 파라미터가 지정되었을 경우, 테이블은 일시 테이블로서 작성됩니다. 일시 테이블은, 그 세션의 끝나, 경우에 따라서는, 현재의 트랜잭션(transaction)의 마지막(후술의ON COMMIT를 참조)에 자동적으로 삭제됩니다. 일시 테이블이 존재하는 경우, 같은 이름을 가지는 기존의 영속 테이블은, schema 수식명으로 참조되어 있지 않은 한, 현재의 세션에서는 비가시가 됩니다. 일시 테이블로 만들어지는 인덱스도, 모두 자동적으로 일시적인 것이 됩니다.
GLOBAL또는LOCAL를TEMPORARY나TEMP의 전에 기술할 수가 있습니다(생략 가능). PostgreSQL에서는, 이것들을 지정해도 동작의 차이는 없습니다. 호환성 (을)를 참조해 주세요.
작성하는 테이블의 이름입니다(schema 수식명에서도 가능).
새로운 테이블로 작성되는 열의 이름입니다.
열의 데이터형입니다. 이것에는, 배열 지정자를 포함할 수가 있습니다. PostgreSQL로 서포트되는 데이터형의 정보에 관한 자세한 것은Chapter 8을 참조해 주세요.
DEFAULT구를 열정의에 붙이면(자), 그 열에 디폴트 데이터치를 할당할 수 있습니다. 값으로 해서 지정하는 것은, 임의의 무변수식입니다(부문의와 현재의 테이블내의 다른 열에 교차 참조는 허가되지 않습니다). 디폴트식의 데이터형은 그 열의 데이터형과 일치할 필요가 있습니다.
디폴트식은, 모든 삽입 조작에 대해, 그 열에 값이 지정되어 있지 않은 경우에 사용됩니다. 열에 디폴트치가 없는 경우, 디폴트치는 NULL가 됩니다.
INHERITS구로 테이블의 일람을 지정하면(자), 새로운 테이블은 지정된 테이블의 모든 열을 자동적으로 계승합니다. 이 구는 생략 가능합니다.
INHERITS를 사용하면(자), 새로운 아이 테이블과 그 친테이블(복수가능)과의 사이에 영속적인 관련이 작성됩니다. 통상, 부모에게로의 schema 수식자는과 같이 아이에게도 전파 합니다. 또, 디폴트에서는, 친테이블의 주사 결과에는 아이 테이블의 데이터가 포함됩니다.
복수의 친테이블에 동일명의 열이 존재하는 경우, 그러한 데이터형이 일치하고 있지 않으면, 에러로서 보고됩니다. 경합이 없으면, 이러한 중복 한 열은 새로운 테이블로 1개의 열의 형태에 융합됩니다. 새로운 테이블의 렬명의 일람에 계승하는 열의 이름이 포함되는 경우도, 그 데이터형은 계승하는 열의 데이터형과 일치하고 있지 않으면 안됩니다. 게다가 그 열정의는 1개에 융합됩니다. 그러나, 동일 명칭의 새로운 열의 선언내에서, 계승하는 열과 동일한 제약을 지정할 필요는 없습니다. 임의의 선언으로 제공되는 제약은, 정리해 머지 되어 모두가 새로운 테이블에 적용됩니다. 새로운 테이블로 명시적으로 열의 디폴트치를 지정했을 경우, 계승한 열선언에 있어서의 모든 디폴트치는 덧쓰기됩니다. 디폴트치를 지정하지 않았던 경우, 친측에서 디폴트치가 지정되고 있을 때는, 그러한 디폴트치가 모두 같은 값이 아니면 안됩니다. 값이 다른 경우는 에러가 됩니다.
LIKE구에 테이블을 지정하면(자), 자동적으로 그 테이블의 모든 렬명, 그 데이터형, 비NULL 제약이 새로운 테이블에 카피됩니다.
INHERITS와의 차이는, 작성한 후, 새로운 테이블과 원의 테이블이 완전하게 분리되는 것입니다. 원의 테이블에의 변경은 새로운 테이블에는 적용되지 않습니다. 또, 원의 테이블을 조작해도 새로운 테이블의 데이터는 발견되지 않습니다.
카피하는 열의 디폴트식은,INCLUDING DEFAULTS가 지정되었을 경우에게만 카피됩니다. 디폴트에서는, 디폴트식이 카피되지 않기 때문에, 새로운 테이블의 카피된 열은 디폴트치로서 NULL를 가지게 됩니다.
비NULL 제약은 항상 새로운 테이블에 카피됩니다. CHECK제약은,INCLUDING CONSTRAINTS가 지정되었을 경우에게만 카피됩니다. 다른 종류의 제약은 결코 카피되지 않습니다. 또, 열제약과 테이블 제약을 구별하지 않습니다. 제약이 요구되는 경우는, 모든 검사 제약이 카피됩니다.
INCLUDING INDEXES구를 지정하지 않는 한, 원의 테이블상의 인덱스는 완전히 새로운 테이블에는 작성되지 않습니다.
또,INHERITS와 달리, 같은 이름의 열이나 제약을 가지는 경우, 카피된 열과 제약은 정리하지 않습니다. 같은 이름이 명시적으로, 혹은 다른LIKE구로 지정되었을 경우, 에러가 통지됩니다.
생략 가능한 열제약, 테이블 제약의 이름입니다. 만약, 이 제약에 위반하면(자), 제약명이 에러 메세지에 포함되게 됩니다. 그러므로,col must be positive(정수가 아니면 안된다)라고 하는 이름의 제약명을 부여하는 것으로, 클라이언트 어플리케이션에 유용한 제약 정보를 건네줄 수가 있습니다. (공백을 포함한 제약명을 지정하는 경우, 이중 인용부호가 필요합니다. ) 지정되지 않으면, 시스템이 이름을 생성합니다.
그 열이 NULL치를 가질 수 없는 것을 지정합니다.
그 열이 NULL치를 가질 수 있는 것을 지정합니다. 이것이 디폴트입니다.
이 구는 비표준적인 SQL 데이타베이스와의 호환성 (을) 위해서만 제공되고 있습니다. 새로운 어플리케이션으로 이것을 사용하는 것은 추천하지 않습니다.
UNIQUE제약은, 테이블의 하나 또는 복수의 열로부터 되는 그룹이, 일의인 값만을 가질 수가 있는 것을 지정합니다. 일의성 테이블 제약의 동작은 일의성렬제약과 같습니다만, 한층 더 복수열에 걸치는 기능을 가집니다.
일의성 제약에서는, NULL치는 동일하다고는 보이고 이룰 수 있는.
각각의 일의성 테이블 제약에는, 그 테이블의 다른 일의성 제약 혹은 프라이머리 키 제약에 의해 이름이 붙여진 열의 집합이란, 다른 이름의 열의 집합을 지정하지 않으면 안됩니다 (같은 이름을 지정하면(자), 같은 제약이 2회 나타나는 만큼 됩니다).
프라이머리 키 제약은, 테이블의 1열 또는 복수열이 일의인(중복이 없다), 비NULL치만을 가지는 것을 지정합니다. 기술적으로는,PRIMARY KEY는 단순한UNIQUE와NOT NULL의 편성입니다. 그러나, 프라이머리 키인 것은 다른 테이블이 그 열집합을 일의인 행 식별자로 간주할 수 있는 것을 의미하므로, 열집합을 프라이머리 키와 특정하면(자), schema 설계에 관한 메타데이타를 제공하게 됩니다.
열제약일까 테이블 제약일까에 관계없이, 1개의 테이블로 지정할 수 있는 프라이머리 키는 1개 뿐입니다.
프라이머리 키 제약에는, 그 테이블에 정의된 다른 일의성 제약으로 지명된 열의 집합과는 다른 편성의 열의 집합을 지정하지 않으면 안됩니다.
CHECK구는, 삽입이나 갱신 조작을 실시하기 위해서(때문에), 새로운 행, 또는 변경하는 행이 채우지 않으면 안 되는, Boolean형의 결과를 돌려주는 식을 지정합니다. 식의 평가가 TRUE 혹은 UNKNOWN가 되면 성공입니다. 행의 삽입, 갱신 조작의 결과, 식이 FALSE가 되는 경우는, 에러 예외가 생성되어 삽입이나 갱신에 의한 데이타베이스의 변경은 행해지지 않습니다. 열제약으로서 지정된 검사 제약은, 그 열의 값만을 참조하지 않으면 안됩니다. 한편, 테이블 제약으로서 나타나는 식은, 복수열을 참조할 수가 있습니다.
현재,CHECK식에는, 부문의나 현재의 행의 열 이외의 값을 포함할 수 없습니다.
이러한 구는, 외부 키 제약을 지정합니다. 외부 키 제약은, 새로운 테이블의 하나 또는 복수의 열의 집합이, 피참조 테이블의 일부의 행의 피참조열(복수가능)에 일치하는 값을 가지지 않으면 안 되는 것을 지정하는 것입니다. refcolumn 가 생략 되었을 경우, reftable 의 프라이머리 키가 사용됩니다. 피참조열은, 피참조 테이블에 대해 일의성 제약 혹은 프라이머리 키 제약을 가진 열이 아니면 안됩니다. 일시 테이블과 영속 테이블과의 사이에 외부 키 제약을 정의할 수 없는 것에 주의해 주세요.
참조열에 삽입된 값은, 피참조 테이블과 피참조열의 값에 대해서, 지정한 조합형으로 조회됩니다. 조합형에는 3 종류가 있습니다. MATCH FULL,MATCH PARTIAL, 디폴트이기도 한MATCH SIMPLE조합형입니다. MATCH FULL는 모든 외부 키열이 NULL가 되는 경우를 제외해, 복수열외부 키가 있는 열이 NULL가 되는 것을 허가하지 않습니다. MATCH SIMPLE조합형은, 외부 키의 다른 부분이 NULL가 아닌 한, 외부 키의 일부를 NULL가 되는 것을 허가합니다. MATCH PARTIAL는 아직 실장되고 있지 않습니다.
게다가 피참조열의 데이터가 변경되었을 경우, 이 테이블의 열의 데이터에 어떠한 동작이 발생합니다. ON DELETE구는, 피참조 테이블의 피참조행이 삭제되었을 경우의 동작을 지정합니다. (와)과 같이ON UPDATE구는, 피참조 테이블의 피참조열이 새로운 값에 갱신되었을 경우의 동작을 지정합니다. 행의 갱신이 있었을 경우에서도, 피참조열이 실제로 변경되지 않는 경우는, 동작은 실행되지 않습니다. 제약이 지연 가능이라고 선언되고 있어도,NO ACTION검사 이외의 참조 동작은 지연 당하지 않습니다. 각 구에 대해, 이하의 동작을 지정 가능합니다.
삭제 혹은 갱신이 외부 키 제약 위반이 되는 것을 나타내는 에러를 발생합니다. 제약이 지연 가능한 경우, 어떠한 참조행이 존재하는 한, 이 에러는 제약의 검사 시점에서 발생합니다. 이것은 디폴트의 동작입니다.
삭제 혹은 갱신이 외부 키 제약 위반이 되는 것을 나타내는 에러를 발생합니다. 검사가 지연 할 수 없는 점을 제외해,NO ACTION와 같습니다.
삭제된 행을 참조하고 있는 행은 모두 삭제합니다. 또, 참조하고 있는 열의 값을, 피참조열의 새로운 값으로 합니다.
참조하는 열(복수가능)을 NULL로 설정합니다.
참조하는 열(복수가능)을 그 디폴트치로 설정합니다.
피참조열이 빈번하게 갱신되는 경우, 외부 키열에 인덱스를 붙여 그 외부 키열에 관련하는 참조 동작이 보다 효율적으로 실행할 수 있도록(듯이) 하는 편이 좋을 것입니다.
제약을 지연 시키는 것이 가능한가 어떤가를 제어합니다. 지연 불가의 제약은 각 커멘드의 뒤 곧바로 검사됩니다. 지연 가능한 제약의 검사는, ( SET CONSTRAINTS 커멘드를 사용해) 트랜잭션(transaction)의 종료시까지 지연 시킬 수가 있습니다. NOT DEFERRABLE가 디폴트입니다. 현재, 외부 키 제약만이 이 구를 받아들일 수가 있습니다. 다른 제약은 지연 시킬 수가 없습니다.
제약이 지연 가능한 경우, 이 구는 제약 검사를 실시하는 디폴트의 시기를 지정합니다. 제약이INITIALLY IMMEDIATE의 경우, 각 문의 실행 후에 검사됩니다. 이것이 디폴트입니다. 제약이INITIALLY DEFERRED의 경우, 트랜잭션(transaction)의 종료시에게만 검사됩니다. 제약 검사의 시기는 SET CONSTRAINTS 커멘드를 사용해 변경할 수가 있습니다.
이 구는, 테이블 또는 인덱스에 대해서 생략 가능한 격납 파라미터를 지정합니다. 자세한 것은 저장(Storage) 파라미터 을 참조해 주세요. 테이블용의WITH에는,OIDS=TRUE(혹은 단순한OIDS)를 포함해, 새로운 테이블의 행을 행에 할당할 수 있었던 OID(오브젝트 식별자)를 가지지 않으면 안 되는 것을 지정할 수도 있습니다. 또,OIDS=FALSE를 포함해, OID를 가지지 않는 것을 지정할 수도 있습니다. OIDS가 지정되지 않는 경우, 디폴트의 설정은default_with_oids설정 파라미터에 의존합니다. (새로운 테이블이 OID를 가지는 테이블에서 계승하는 경우, 커멘드로OIDS=FALSE와 지정해도 강제적으로OIDS=TRUE 가 됩니다. )
OIDS=FALSE가 명시적 또는 암묵적으로 지정되고 있는 경우, 새로운 테이블은 OID를 격납하지 않습니다. 또, 삽입되는 행에는 OID를 할당할 수 없습니다. 이러한 동작은 일반적으로 유익하다라고 생각됩니다. 그것은, OID의 사용을 억제해 32 비트의 OID 카운터의 회전 주기를 연장할 수 있기 (위해)때문에입니다. 카운터가 일주 하면(자) OID의 일의성을 보증할 수 없게 되므로, 그 유용성을 감소시키게 됩니다. 또, OID를 없애는 것으로, 테이블 1행 당(대부분의 머신으로) 4바이트분 , 테이블을 디스크에 격납하기 위한 용량을 경감하므로, 다소 성능이 향상합니다.
테이블의 작성 후에 OID를 삭제하려면, ALTER TABLE 를 사용해 주세요.
이것은 낡은 구문으로, 각각WITH (OIDS) and WITH (OIDS=FALSE)와 같습니다. OIDS의 설정과 격납 파라미터의 설정의 양쪽 모두를 지정하고 싶은 경우는, 상술의WITH ( ... )(을)를 사용하지 않으면 안됩니다.
ON COMMIT를 사용해, 트랜잭션(transaction) 블록의 종료시점에서의 일시 테이블의 동작을 제어할 수가 있습니다. 이하의 3개의 옵션이 있습니다.
트랜잭션(transaction)의 종료시점으로써, 특별한 동작은 행해지지 않습니다. 이것이 디폴트의 동작입니다.
일시 테이블내의 모든 행은, 각 트랜잭션(transaction) 블록의 마지막으로 삭제됩니다. 기본적으로는, 위탁의 번에 자동적으로 TRUNCATE >가 실행됩니다.
일시 테이블은, 현재의 트랜잭션(transaction) 블록의 종료시점으로써 삭제됩니다.
tablespace 는, 새로운 테이블이 작성되는 테이블 공간명입니다. 지정되지 않은 경우,default_tablespace이 사용되거나, 또는 default_tablespace가 빈 문자열인 경우 데이터베이스가 생성된 기본 테이블스페이스를 사용합니다.
이 절에 의해,UNIQUE또는PRIMARY KEY제약에 관련한 인덱스를 작성하는 테이블 공간을 선택할 수가 있습니다. 지정되어 있지 않은 경우,default_tablespace가 지정되거나, 만약 default_tablespace가 빈 문자열이라면 기본 테이블 스테이스가 지정됩니다.
WITH구에 의해, 테이블 및UNIQUE또는PRIMARY KEY제약과 관련있던 인덱스의격납 파라미터를 지정할 수가 있습니다. 인덱스의 격납 파라미터에 대해서는 CREATE INDEX 으로 설명합니다. 현재, 테이블에서는 이하의 격납 파라미터만이 설정 가능합니다.
테이블의 fillfactor는 10에서 100까지의 사이의 비율(퍼센트)입니다. 100(완전하게 모두 사용)이 디폴트입니다. 보다 작은 값을 지정하면(자),INSERT조작은 지정한 비율까지 밖에 테이블 페이지를 사용하지 않습니다. 각 페이지의 나머지의 부분은, 그 페이지내의 행 갱신용으로 예약됩니다. 이것에 의해UPDATE는, 원의 행과 같은 페이지상에 갱신 끝난 행의 복제를 격납할 수가 있게 됩니다. 이것은 다른 페이지에 갱신 끝난 행의 복제를 격납 하는 것보다도 효율적입니다. 항목의 갱신이 전혀 없는 테이블에서는, 완전하게 모든 것을 사용하는 것이 최선의 선택입니다. 그러나, 갱신이 매우 많은 테이블에서는 보다 작은 fillfactor가 적절합니다.
신규의 어플리케이션으로 OID를 사용하는 것은 추천하지 않습니다. 할 수 있는 한, 테이블의 프라이머리 키로서SERIAL나 다른 순서 제네레이터를 사용하는 (분)편이 바람직하다고 생각됩니다. 그러나, 어플리케이션이 테이블의 특정의 행을 식별하기 위해서 OID를 사용하는 경우는, 그 테이블의oid열에 일의성 제약을 작성하는 것을 추천 합니다. 이것에 의해, 카운터가 일주 해 버렸을 경우에서도, 테이블내의 OID로 일의에 행을 식별할 수 있는 것이 보증되기 때문입니다. OID가 테이블 전체로 일의이다고 생각하는 것은 멈추어 주세요. 데이타베이스 전체로 일의인 식별자가 필요한 경우는,tableoid와 행의 OID의 편성을 사용해 주세요.
Tip: OIDS=FALSE의 사용은, 프라이머리 키가 없는 테이블에서는 추천 되지 않습니다. OID도 일의인 데이터 키도 존재하지 않으면 특정행을 식별하는 것이 어려워지기 때문입니다.
PostgreSQL는 자동적으로 각 일의성 제약과 프라이머리 키 제약에 대해서 인덱스를 작성해, 그 일의성을 확실한 것으로 합니다. 따라서, 프라이머리 키의 열에 명시적인 인덱스를 작성하는 것은 필요 없습니다 (상세한 것에 대하여는 CREATE INDEX 을 참조해 주세요).
현재의 실장에서는, 일의성 제약과 프라이머리 키는 계승되지 않습니다. 이것은, 계승과 일의성 제약을 조합하면(자) 장해가 발생하기 때문입니다.
테이블은 1600열이상의 열을 가질 수 없습니다 (타풀장의 제한에 의해 실제의 제한은 좀 더 낮아집니다).
films테이블과distributors테이블을 작성합니다.
CREATE TABLE films (
code char(5) CONSTRAINT firstkey PRIMARY KEY,
title varchar(40) NOT NULL,
did integer NOT NULL,
date_prod date,
kind varchar(10),
len interval hour to minute
);
CREATE TABLE distributors (
did integer PRIMARY KEY DEFAULT nextval('serial'),
name varchar(40) NOT NULL CHECK (name <> '')
);
2 차원 배열을 가지는 테이블을 작성합니다.
CREATE TABLE array_int (
vector int[][]
);
films테이블에 일의성 테이블 제약을 정의합니다. 일의성 테이블 제약은 테이블의 하나 이상의 열에 정의할 수가 있습니다.
CREATE TABLE films (
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
CONSTRAINT production UNIQUE(date_prod)
);
검사열제약을 정의합니다.
CREATE TABLE distributors (
did integer CHECK (did > 100),
name varchar(40)
);
검사 테이블 제약을 정의합니다.
CREATE TABLE distributors (
did integer,
name varchar(40)
CONSTRAINT con1 CHECK (did > 100 AND name <> '')
);
films테이블에 프라이머리 키 테이블 제약을 정의합니다.
CREATE TABLE films (
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
CONSTRAINT code_title PRIMARY KEY(code, title)
);
distributors테이블에 프라이머리 키 제약을 정의합니다. 이하의 2개의 예는 같은 것입니다. 전자는 테이블 제약 구문을 사용해, 후자는 열제약 구문을 사용합니다.
CREATE TABLE distributors (
did integer,
name varchar(40),
PRIMARY KEY(did)
);
CREATE TABLE distributors (
did integer PRIMARY KEY,
name varchar(40)
);
이하에서는,name열의 디폴트치에 리터럴 정수를 할당하고 있습니다. 또,did열의 디폴트치로서 순서 오브젝트의 다음의 값이 생성되도록(듯이) 조정하고 있습니다. modtime의 디폴트치는, 그 행이 삽입되었을 때 각이 됩니다.
CREATE TABLE distributors (
name varchar(40) DEFAULT 'Luso Films',
did integer DEFAULT nextval('distributors_serial'),
modtime timestamp DEFAULT current_timestamp
);
2개의NOT NULL열제약을distributors테이블에 정의합니다.
그 중 1개에는 명시적인 이름을 붙이고 있습니다.
CREATE TABLE distributors (
did integer CONSTRAINT no_null NOT NULL,
name varchar(40) NOT NULL
);
name열에 대해, 일의성 제약을 정의합니다.
CREATE TABLE distributors (
did integer,
name varchar(40) UNIQUE
);
위를 테이블 제약으로서 지정합니다.
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name)
);
테이블과 그 일의성 인덱스에70%의 fill 팩터를 지정해, 같은 테이블을 작성합니다.
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name) WITH (fillfactor=70)
)
WITH (fillfactor=70);
diskvol1테이블 공간에cinemas테이블을 작성합니다.
CREATE TABLE cinemas (
id serial,
name text,
location text
) TABLESPACE diskvol1;
CREATE TABLE는, 이하의 일람을 제외해, 표준SQL에 따릅니다.
CREATE TEMPORARY TABLE는 표준 SQL에 유사하고 있습니다만, 그 효과는 같지는 않습니다. 표준에서는, 일시 테이블은 한 번만 정의되어 그것을 필요로 하는 세션 마다 자동적으로(하늘의 내용으로 시작되는 형태로) 출현합니다. PostgreSQL에서는, 이것과 달리, 각 세션으로 독자적으로, 사용하는 일시 테이블용의CREATE TEMPORARY TABLE커멘드를 발행하지 않으면 안됩니다. 이것에 의해, 다른 세션으로 같은 이름의 일시 테이블을 다른 목적으로 사용할 수가 있습니다. 한편, 표준의 방법에서는, 어느 일시 테이블명을 가지는 인스턴스가, 모두 동일한 테이블 구조를 갖는다고 하는 제한이 있습니다.
표준에 있어서의 이러한 일시 테이블의 동작 정의는 대부분 무시되고 있습니다. 이 점에서의PostgreSQL의 동작은, 다른 많은 SQL 데이타베이스와 닮아 있습니다.
표준에 있어서의, 글로벌 일시 테이블과 로컬 일시 테이블의 구별은PostgreSQL에는 없습니다. 이 구별은 모듈이라고 하는 개념에 의존한 것입니다만,PostgreSQL에는 모듈 개념이 없기 때문입니다. 호환성을 보관 유지하기 위해(때문에),PostgreSQL는 일시 테이블의 선언에 대해GLOBAL와LOCAL키워드를 받아들입니다만, 이것들에는 무슨 효과도 없습니다.
일시 테이블용의ON COMMIT구도 또, 표준 SQL에 유사하고 있습니다만, 몇 점의 차이가 있습니다. ON COMMIT구가 생략 되었을 경우, SQL에서는, 디폴트의 동작은ON COMMIT DELETE ROWS이다고 규정하고 있습니다. 그러나,PostgreSQL에서의 디폴트의 동작은ON COMMIT PRESERVE ROWS입니다. 또,ON COMMIT DROP는 SQL에는 없습니다.
표준 SQL에서는,CHECK열제약은 그것을 적용하는 열만을 참조할 수 있어 복수의 열을 참조할 수 있는 것은CHECK테이블 제약뿐이라고 되고 있습니다. PostgreSQL에는 이 제한은 없습니다. 열검사 제약과 테이블 검사 제약을 같은 것으로 해 취급하고 있습니다.
NULL "제약"(실제로는 비제약)은, 표준 SQL에 대한PostgreSQL의 확장으로, 다른 몇개의 데이타베이스 시스템과의 호환성을 위해서(때문에) 포함되어 있습니다(NOT NULL제약과 대칭이 됩니다). 어떤 열에 대해서도 디폴트가 되기 (위해)때문에, 이것은 노이즈에 지나지 않습니다.
INHERITS구에 의한 복수 계승은,PostgreSQL의 언어 확장입니다. SQL:1999이후에서는, 다른 구문과 의미 체계에 의한 단일 계승을 정의하고 있습니다. 현재, SQL:1999 방식의 계승은PostgreSQL에서는 서포트되고 있지 않습니다.