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

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

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

지정되면, 해당 테이블이 unlogged 테이블로 생성됩니다. Unlogged 테이블에 기록되는 데이터는 write-ahead 로그 (29장참고)에 기록되지 않으며, 때문에 일반 테이블보다 확연히 빠르게 기록됩니다. 하지만, 이는 사고에 안전하지 않습니다. 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 설정 또한, 부모 테이블에서 복사됩니다.

If a column in the parent table is an identity column, that property is not inherited. A column in the child table can be declared identity column if desired.

The optional PARTITION BY clause specifies a strategy of partitioning the table. The table thus created is called a partitioned table. The parenthesized list of columns or expressions forms the partition key for the table. When using range or hash partitioning, the partition key can include multiple columns or expressions (up to 32, but this limit can be altered when building PostgreSQL), but for list partitioning, the partition key must consist of a single column or expression.

Range and list partitioning require a btree operator class, while hash partitioning requires a hash operator class. If no operator class is specified explicitly, the default operator class of the appropriate type will be used; if no default operator class exists, an error will be raised. When hash partitioning is used, the operator class used must implement support function 2 (see 37.16.3절 for details).

A partitioned table is divided into sub-tables (called partitions), which are created using separate CREATE TABLE commands. The partitioned table is itself empty. A data row inserted into the table is routed to a partition based on the value of columns or expressions in the partition key. If no existing partition matches the values in the new row, an error will be reported.

Partitioned tables do not support EXCLUDE constraints; however, you can define these constraints on individual partitions.

See 5.11절 for more discussion on table partitioning.

Creates the table as a partition of the specified parent table. The table can be created either as a partition for specific values using FOR VALUES or as a default partition using DEFAULT. Any indexes, constraints and user-defined row-level triggers that exist in the parent table are cloned on the new partition.

The partition_bound_spec must correspond to the partitioning method and partition key of the parent table, and must not overlap with any existing partition of that parent. The form with IN is used for list partitioning, the form with FROM and TO is used for range partitioning, and the form with WITH is used for hash partitioning.

partition_bound_expr is any variable-free expression (subqueries, window functions, aggregate functions, and set-returning functions are not allowed). Its data type must match the data type of the corresponding partition key column. The expression is evaluated once at table creation time, so it can even contain volatile expressions such as CURRENT_TIMESTAMP.

When creating a list partition, NULL can be specified to signify that the partition allows the partition key column to be null. However, there cannot be more than one such list partition for a given parent table. NULL cannot be specified for range partitions.

When creating a range partition, the lower bound specified with FROM is an inclusive bound, whereas the upper bound specified with TO is an exclusive bound. That is, the values specified in the FROM list are valid values of the corresponding partition key columns for this partition, whereas those in the TO list are not. Note that this statement must be understood according to the rules of row-wise comparison (9.24.5절). For example, given PARTITION BY RANGE (x,y), a partition bound FROM (1, 2) TO (3, 4) allows x=1 with any y>=2, x=2 with any non-null y, and x=3 with any y<4.

The special values MINVALUE and MAXVALUE may be used when creating a range partition to indicate that there is no lower or upper bound on the column's value. For example, a partition defined using FROM (MINVALUE) TO (10) allows any values less than 10, and a partition defined using FROM (10) TO (MAXVALUE) allows any values greater than or equal to 10.

When creating a range partition involving more than one column, it can also make sense to use MAXVALUE as part of the lower bound, and MINVALUE as part of the upper bound. For example, a partition defined using FROM (0, MAXVALUE) TO (10, MAXVALUE) allows any rows where the first partition key column is greater than 0 and less than or equal to 10. Similarly, a partition defined using FROM ('a', MINVALUE) TO ('b', MINVALUE) allows any rows where the first partition key column starts with "a".

Note that if MINVALUE or MAXVALUE is used for one column of a partitioning bound, the same value must be used for all subsequent columns. For example, (10, MINVALUE, 0) is not a valid bound; you should write (10, MINVALUE, MINVALUE).

Also note that some element types, such as timestamp, have a notion of "infinity", which is just another value that can be stored. This is different from MINVALUE and MAXVALUE, which are not real values that can be stored, but rather they are ways of saying that the value is unbounded. MAXVALUE can be thought of as being greater than any other value, including "infinity" and MINVALUE as being less than any other value, including "minus infinity". Thus the range FROM ('infinity') TO (MAXVALUE) is not an empty range; it allows precisely one value to be stored — "infinity".

If DEFAULT is specified, the table will be created as the default partition of the parent table. This option is not available for hash-partitioned tables. A partition key value not fitting into any other partition of the given parent will be routed to the default partition.

When a table has an existing DEFAULT partition and a new partition is added to it, the default partition must be scanned to verify that it does not contain any rows which properly belong in the new partition. If the default partition contains a large number of rows, this may be slow. The scan will be skipped if the default partition is a foreign table or if it has a constraint which proves that it cannot contain rows which should be placed in the new partition.

When creating a hash partition, a modulus and remainder must be specified. The modulus must be a positive integer, and the remainder must be a non-negative integer less than the modulus. Typically, when initially setting up a hash-partitioned table, you should choose a modulus equal to the number of partitions and assign every table the same modulus and a different remainder (see examples, below). However, it is not required that every partition have the same modulus, only that every modulus which occurs among the partitions of a hash-partitioned table is a factor of the next larger modulus. This allows the number of partitions to be increased incrementally without needing to move all the data at once. For example, suppose you have a hash-partitioned table with 8 partitions, each of which has modulus 8, but find it necessary to increase the number of partitions to 16. You can detach one of the modulus-8 partitions, create two new modulus-16 partitions covering the same portion of the key space (one with a remainder equal to the remainder of the detached partition, and the other with a remainder equal to that value plus 8), and repopulate them with data. You can then repeat this -- perhaps at a later time -- for each modulus-8 partition until none remain. While this may still involve a large amount of data movement at each step, it is still better than having to create a whole new table and move all the data at once.

A partition must have the same column names and types as the partitioned table to which it belongs. Modifications to the column names or types of a partitioned table will automatically propagate to all partitions. CHECK constraints will be inherited automatically by every partition, but an individual partition may specify additional CHECK constraints; additional constraints with the same name and condition as in the parent will be merged with the parent constraint. Defaults may be specified separately for each partition. But note that a partition's default value is not applied when inserting a tuple through a partitioned table.

Rows inserted into a partitioned table will be automatically routed to the correct partition. If no suitable partition exists, an error will occur.

Operations such as TRUNCATE which normally affect a table and all of its inheritance children will cascade to all partitions, but may also be performed on an individual partition. Note that dropping a partition with DROP TABLE requires taking an ACCESS EXCLUSIVE lock on the parent table.

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

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

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

The optional like_option clauses specify which additional properties of the original table to copy. Specifying INCLUDING copies the property, specifying EXCLUDING omits the property. EXCLUDING is the default. If multiple specifications are made for the same kind of object, the last one is used. The available options are:

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

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

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

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

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

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

Currently, CHECK expressions cannot contain subqueries nor refer to variables other than columns of the current row (see 5.4.1절). The system column tableoid may be referenced, but not any other system column.

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이 기본값이 됩니다.

This clause creates the column as a generated column. The column cannot be written to, and when read the result of the specified expression will be returned.

The keyword STORED is required to signify that the column will be computed on write and will be stored on disk.

The generation expression can refer to other columns in the table, but not other generated columns. Any functions and operators used must be immutable. References to other tables are not allowed.

This clause creates the column as an identity column. It will have an implicit sequence attached to it and the column in new rows will automatically have values from the sequence assigned to it. Such a column is implicitly NOT NULL.

The clauses ALWAYS and BY DEFAULT determine how explicitly user-specified values are handled in INSERT and UPDATE commands.

In an INSERT command, if ALWAYS is selected, a user-specified value is only accepted if the INSERT statement specifies OVERRIDING SYSTEM VALUE. If BY DEFAULT is selected, then the user-specified value takes precedence. See INSERT for details. (In the COPY command, user-specified values are always used regardless of this setting.)

In an UPDATE command, if ALWAYS is selected, any update of the column to any value other than DEFAULT will be rejected. If BY DEFAULT is selected, the column can be updated normally. (There is no OVERRIDING clause for the UPDATE command.)

The optional sequence_options clause can be used to override the options of the sequence. See CREATE SEQUENCE for details.

UNIQUE 제약은 테이블 내에서 고유값만 포함할 수 있는 하나 이상의 열 그룹을 지정합니다. The behavior of a unique table constraint is the same as that of a unique column constraint, with the additional capability to span multiple columns. The constraint therefore enforces that any two rows must differ in at least one of these columns.

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

각 unique 제약에서 지정한 열 집합은, 다른 unique나 primary key 제약에서 지정한 열 집합과 달라야 합니다. (중복되면, 유니크 제약조건은 무시 된다.)

When establishing a unique constraint for a multi-level partition hierarchy, all the columns in the partition key of the target partitioned table, as well as those of all its descendant partitioned tables, must be included in the constraint definition.

Adding a unique constraint will automatically create a unique btree index on the column or group of columns used in the constraint.

The optional INCLUDE clause adds to that index one or more columns that are simply “payload”: uniqueness is not enforced on them, and the index cannot be searched on the basis of those columns. However they can be retrieved by an index-only scan. Note that although the constraint is not enforced on included columns, it still depends on them. Consequently, some operations on such columns (e.g., DROP COLUMN) can cause cascaded constraint and index deletion.

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. However, 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.

When placed on a partitioned table, PRIMARY KEY constraints share the restrictions previously described for UNIQUE constraints.

Adding a PRIMARY KEY constraint will automatically create a unique btree index on the column or group of columns used in the constraint.

The optional INCLUDE clause adds to that index one or more columns that are simply “payload”: uniqueness is not enforced on them, and the index cannot be searched on the basis of those columns. However they can be retrieved by an index-only scan. Note that although the constraint is not enforced on included columns, it still depends on them. Consequently, some operations on such columns (e.g., DROP COLUMN) can cause cascaded constraint and index deletion.

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

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

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

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

이 절은, 신규 테이블의 하나 이상의 열 그룹이, 참조되는 테이블의 행에 있는 열(들)의 값과 일치하도록 요구하는, 외래키 제약을 지정합니다. refcolumn이 생략되면, reftable의 primary key가 사용됩니다. The referenced columns must be the columns of a non-deferrable unique or primary key constraint in the referenced table. The user must have REFERENCES permission on the referenced table (either the whole table, or the specific referenced columns). The addition of a foreign key constraint requires a SHARE ROW EXCLUSIVE lock on the referenced table. Note that foreign key constraints cannot be defined between temporary tables and permanent tables.

지정된 일치 조건을 이용하여, 참조하는 열(들)에 삽입되는 값이 참조되는 테이블과 참조되는 열의 값에 대응됩니다. 다음의 세가지 일치 조건: 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 명령으로 변경할 수 있습니다.

This optional clause specifies the table access method to use to store the contents for the new table; the method needs be an access method of type TABLE. See 60장 for more information. If this option is not specified, the default table access method is chosen for the new table. See default_table_access_method for more information.

이절은 테이블이나 인덱스에 대한 선택적 storage parameter를 지정합니다. 더 많은 정보는 스토리지 매개 변수 부분을 참고하십시오. For backward-compatibility the WITH clause for a table can also include OIDS=FALSE to specify that rows of the new table should not contain OIDs (object identifiers), OIDS=TRUE is not supported anymore.

This is backward-compatible syntax for declaring a table WITHOUT OIDS, creating a table WITH OIDS is not supported anymore.

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

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

이 절은 UNIQUE, PRIMARY KEY, 또는 EXCLUDE 제약과 연관된 인덱스가 생성될 테이블스페이스를 선택할 수 있게 합니다. 지정하지 않으면 default_tablespace가 제시되며, 임시 테이블인 경우엔 temp_tablespaces가 됩니다. For partitioned tables, since no storage is required for the table itself, the tablespace specified overrides default_tablespace as the default tablespace to use for any newly created partitions when no other tablespace is explicitly specified.