Se especificado, a tabela é criada como tabela temporária. As tabelas temporárias são excluídas automaticamente no final da sessão ou, opcionalmente, no final da transação corrente (veja ON COMMIT abaixo). O caminho de procura padrão inclui primeiro o esquema temporário, portanto, as tabelas permanentes existentes com nomes idênticos não serão escolhidas para os novos planos enquanto a tabela temporária existir, a menos que sejam referenciadas com nomes qualificados pelo esquema. Quaisquer índices criados em tabela temporária também são automaticamente temporários.

O processo de auto limpeza (Autovacuum) não pode acessar e, portanto, não pode limpar ou analisar, tabelas temporárias. Por este motivo, as operações apropriadas de limpeza e análise devem ser executadas por meio de comandos SQL da sessão. Por exemplo, se uma tabela temporária for usada em consultas complexas, é aconselhável executar ANALYZE na tabela temporária após ela ser preenchida com dados.

Opcionalmente, podem ser escritos GLOBAL ou LOCAL antes de TEMPORARY ou TEMP. No momento, isto não faz diferença no PostgreSQL, estando em obsolescência; veja Conformidade abaixo.

Se especificado, a tabela será criada como uma tabela sem registro de transações (Unlogged). Os dados escritos nas tabelas sem registro de transações não são escritos no arquivo de registro de transações (veja Confiabilidade e o Registro de Escrita Antecipada), o que as torna consideravelmente mais rápidas do que as tabelas comuns. Entretanto, elas não são à prova de falhas: a tabela sem registro de transações é automaticamente truncada após uma falha ou desligamento incorreto. O conteúdo da tabela sem registro de transações também não é replicado para servidores em espera (standby). Quaisquer índices criados em tabela sem registro de transações também são automaticamente sem registro de transações.

Caso esta opção seja especificada, quaisquer sequências criadas juntamente com a tabela sem registro de transações (para colunas de identidade ou seriais) também serão criadas como sem registro de transações.

Esta sintaxe não tem suporte em tabelas particionadas.

Não relata erro se já existir uma relação com o mesmo nome. É emitido um aviso neste caso. Note não haver garantia de que a relação existente seja parecida com a tabela a ser criada.

O nome (opcionalmente qualificado pelo esquema) da tabela a ser criada.

Cria uma tabela tipada, cuja estrutura deriva do tipo de dados composto independente especificado (isto é, um tipo de dados criado usando CREATE TYPE), embora também produza um novo tipo de dados composto. A tabela terá uma dependência do tipo de dados referenciado, significando que ações em cascata de alteração e exclusão neste tipo de dados serão propagadas para a tabela.

Uma tabela tipada sempre tem os mesmos nomes de coluna e tipos de dados que o tipo de dados do qual ela deriva, portanto, não se pode especificar colunas adicionais. Mas o comando CREATE TABLE pode adicionar valores padrão e restrições à tabela, bem como especificar parâmetros de armazenamento.

O nome da coluna a ser criada na nova tabela.

O tipo de dados da coluna. Pode incluir especificadores de matriz. Para obter mais informações sobre os tipos de dados com suporte pelo PostgreSQL, veja Tipos de dados.

A cláusula COLLATE atribui uma ordenação à coluna (que deve ser de um tipo de dados ordenável). Se não for especificada, será usada a ordenação padrão do tipo de dados da coluna.

Esta sintaxe define o modo de armazenamento da coluna. Controla se esta coluna é mantida na tabela principal ou em uma tabela secundária TOAST, e se os dados devem ser comprimidos ou não. PLAIN deve ser usado para valores de comprimento fixo, como números inteiros (integer), armazenados na tabela principal sem compressão. MAIN é para dados armazenados na tabela principal potencialmente compressíveis. EXTERNAL é para dados externos não comprimidos, e EXTENDED é para dados externos comprimidos. Escrever DEFAULT define o modo de armazenamento para o modo padrão do tipo de dados da coluna. EXTENDED é o padrão para a maioria dos tipos de dados permitem armazenamento diferente de PLAIN. O uso de EXTERNAL fará com que as operações de sub-cadeia de caracteres em valores muito grandes dos tipos de dados text e bytea sejam executadas mais rapidamente, à custa de maior espaço de armazenamento. Veja TOAST para obter mais informações.

A cláusula COMPRESSION define o método de compressão para a coluna. A compressão tem suporte apenas para os tipos de dados de largura variável, sendo usada apenas quando o modo de armazenamento da coluna é main ou extended. (Veja ALTER TABLE para obter informações sobre os modos de armazenamento de coluna.) Definir esta propriedade para tabela particionada não tem efeito direto, porque estas tabelas não possuem armazenamento próprio, mas o valor configurado será herdado pelas partições recém-criadas. Os métodos de compressão com suporte são pglz e lz4. (lz4 está disponível apenas se foi usado --with-lz4 ao construir o PostgreSQL.) Além desses, o método_de_compressão pode ser default para especificar explicitamente o comportamento padrão, que é consultar o parâmetro de configuração default_toast_compression no momento da inserção de dados para determinar o método a ser usado.

A cláusula opcional INHERITS especifica uma lista de tabelas das quais a nova tabela herda automaticamente todas as colunas. As tabelas mãe podem ser tabelas simples ou tabelas estrangeiras.

O uso de INHERITS cria um relacionamento persistente entre a nova tabela filha e sua(s) tabela(s) mãe. As modificações de esquema na(s) mãe(s) normalmente se propagam também para as filhas e, por padrão, os dados da tabela filha são incluídos nas varreduras da(s) mãe(s).

Se existir o mesmo nome de coluna em mais de uma tabela mãe, será relatado erro, a menos que os tipos de dados das colunas correspondam em cada uma das tabelas mãe. Se não houver conflito, as colunas duplicadas serão mescladas para formar uma única coluna na nova tabela. Se a lista de nomes de coluna da nova tabela contiver um nome de coluna que também seja herdado, o tipo de dados também deverá corresponder à(s) coluna(s) herdada(s), e as definições de coluna serão mescladas em uma. Se a nova tabela especificar explicitamente um valor padrão para a coluna, este padrão substituirá quaisquer padrões das declarações herdadas da coluna. Caso contrário, todas as mães que especificarem valor padrão para a coluna deverão especificar o mesmo valor padrão, ou será relatado erro.

As restrições CHECK são mescladas essencialmente da mesma maneira que as colunas: se várias tabelas mãe e/ou a nova definição de tabela contiverem restrições CHECK com nomes idênticos, todas estas restrições deverão ter a mesma expressão de verificação, ou será relatado erro. As restrições com o mesmo nome e expressão serão mescladas em uma cópia. Uma restrição marcada como NO INHERIT na tabela mãe não será considerada. Note que uma restrição CHECK sem nome na nova tabela nunca será mesclada, porque sempre será escolhido um nome único para ela.

As configurações de coluna STORAGE também são copiadas das tabelas mãe.

Se a coluna na tabela mãe for uma coluna de identidade, esta propriedade não será herdada. Uma coluna na tabela filha pode ser declarada como coluna de identidade, se desejado.

A cláusula opcional PARTITION BY especifica a estratégia de particionamento da tabela. A tabela assim criada é chamada de tabela particionada. A lista de colunas ou expressões entre parênteses forma a chave de partição da tabela. Quando se usa o particionamento por intervalo ou hash, a chave de partição pode incluir várias colunas ou expressões (até 32, mas este limite pode ser alterado ao construir o PostgreSQL), mas para o particionamento de lista, a chave de partição deve consistir em uma única coluna ou expressão.

O particionamento de intervalo e lista requer uma classe de operador Árvore-B, enquanto o particionamento de hash requer uma classe de operador hash. Se não for especificada nenhuma classe de operador explicitamente, a classe de operador padrão do tipo apropriado será usada; se não existir nenhuma classe de operador padrão, será relatado erro. Quando é usado o particionamento de hash, a classe de operador usada deve implementar a função de suporte 2 (veja Rotinas de suporte do método de índice para obter detalhes).

Uma tabela particionada é dividida em subtabelas (chamadas partições), criadas usando comandos CREATE TABLE distintos. A própria tabela particionada fica vazia. Uma linha de dados inserida na tabela é roteada para uma partição com base no valor de colunas ou expressões na chave de partição. Se nenhuma partição existente corresponder aos valores na nova linha, será relatado erro.

Veja Particionamento de tabela para obter mais informações sobre particionamento de tabelas.

Cria a tabela como partição da tabela mãe especificada. A tabela pode ser criada como uma partição para valores específicos usando FOR VALUES, ou como a partição padrão usando DEFAULT. Quaisquer índices, restrições e gatilhos no nível de linha definidos pelo usuário existentes na tabela mãe são clonados na nova partição.

A especificação_de_limite_de_partição deve corresponder ao método de particionamento e à chave de partição da tabela mãe, e não deve se sobrepor a nenhuma partição existente dessa mãe. A forma com IN é usada para particionamento de lista, a forma com FROM e TO é usada para particionamento de intervalo, e a forma com WITH é usada para particionamento de hash.

A expressão_de_limite_de_partição é qualquer expressão livre de variável (subconsultas, funções de janela, funções de agregação e funções que retornam conjunto não são permitidas). Seu tipo de dados deve corresponder ao tipo de dados da coluna de chave de partição correspondente. A expressão é avaliada uma vez no momento da criação da tabela, portanto, pode até conter expressões voláteis como CURRENT_TIMESTAMP.

Ao criar uma partição de lista, pode ser especificado NULL para indicar que a partição permite que a coluna de chave de partição receba o valor NULL. No entanto, não pode haver mais de uma partição de lista para uma determinada tabela mãe. Não pode ser especificado NULL para partições de intervalo.

Ao criar uma partição de intervalo, o limite inferior especificado com FROM é um limite inclusivo, enquanto o limite superior especificado com TO é um limite exclusivo. Ou seja, os valores especificados na lista FROM são valores válidos das colunas de chave de partição correspondentes para esta partição, enquanto aqueles na lista TO não são. Note que esta declaração deve ser entendida segundo as regras de comparação por linha (Comparação de construtor de linha). Por exemplo, dado PARTITION BY RANGE (x,y), uma partição definida usando FROM (1, 2) TO (3, 4), permite x=1 com qualquer y>=2, x=2 com qualquer y não nulo, e x=3 com qualquer y<4.

Podem ser usados os valores especiais MINVALUE e MAXVALUE ao criar uma partição de intervalo, para indicar não haver limite inferior ou superior no valor da coluna. Por exemplo, uma partição definida usando FROM (MINVALUE) TO (10) permite qualquer valor menor que 10, e uma partição definida usando FROM (10) TO (MAXVALUE) permite qualquer valor maior ou igual a 10.

Ao criar uma partição de intervalo envolvendo mais de uma coluna, também pode fazer sentido usar MAXVALUE como parte do limite inferior, e MINVALUE como parte do limite superior. Por exemplo, uma partição definida usando FROM (0, MAXVALUE) TO (10, MAXVALUE) permite qualquer linha em que a primeira coluna de chave de partição seja maior que 0, e menor ou igual a 10. Da mesma forma, uma partição definida usando FROM ('a', MINVALUE) TO ('b', MINVALUE) permite qualquer linha em que a primeira coluna de chave de partição comece com "a".

Note que se for usado MINVALUE ou MAXVALUE para uma coluna de limite de particionamento, o mesmo valor deverá ser usado para todas as colunas subsequentes. Por exemplo, (10, MINVALUE, 0) não é um limite válido; deve ser escrito (10, MINVALUE, MINVALUE).

Note também que alguns tipos de dados, como timestamp, possuem a noção de "infinity", que é apenas mais um valor que pode ser armazenado, sendo diferente de MINVALUE e MAXVALUE, que não são valores reais que podem ser armazenados, mas sim formas de dizer que o valor é ilimitado. MAXVALUE pode ser visto como maior que qualquer outro valor, inclusive "infinity", e MINVALUE pode ser visto como sendo menor que qualquer outro valor, inclusive "minus infinity". Assim, o intervalo FROM ('infinity') TO (MAXVALUE) não é um intervalo vazio; ele permite que precisamente um valor seja armazenado — "infinity".

Se for especificado DEFAULT, a tabela será criada como a partição padrão da tabela mãe. Esta opção não está disponível para tabelas particionadas por hash. Um valor de chave de partição que não se ajusta a nenhuma outra partição definida da tabela mãe, será roteado para a partição padrão.

Quando uma tabela tem a partição DEFAULT existente, e uma nova partição é adicionada a esta tabela, a partição padrão deve ser examinada para verificar se não contém nenhuma linha que se adéque à nova partição. Se a partição padrão tiver muitas linhas, este processo pode ser lento. A verificação será ignorada se a partição padrão for uma tabela estrangeira, ou se tiver uma restrição provando que não pode conter linhas que devem ser colocadas na nova partição.

Ao criar uma partição de hash, devem ser especificados um módulo e um resto. O módulo deve ser um número inteiro positivo, e o resto deve ser um número inteiro não negativo menor que o módulo. Normalmente, ao configurar inicialmente uma tabela particionada por hash, deve-se escolher um módulo igual ao número de partições, e atribuir a cada tabela o mesmo módulo e um resto diferente (veja os exemplos abaixo). Entretanto, não é necessário que todas as partições tenham o mesmo módulo, apenas que todo módulo que ocorre entre as partições de uma tabela particionada por hash seja um fator do próximo módulo maior. Isto permite que o número de partições seja aumentado incrementalmente sem precisar mover todos os dados de uma só vez. Por exemplo, supondo que se tenha uma tabela particionada por hash com 8 partições, cada uma das quais possui módulo 8, mas se ache necessário aumentar o número de partições para 16. Pode-se separar uma das partições Módulo-8, criar duas novas partições Módulo-16, cobrindo a mesma parte do espaço-chave (uma com resto igual ao resto da partição separada, e a outra com resto igual a este valor mais 8) e repovoar com dados. Este procedimento pode ser repetido – talvez mais tarde – para cada Módulo-8 até que não reste mais nenhum. Embora isto ainda possa envolver uma grande quantidade de movimento de dados em cada etapa, ainda é melhor do que ter que criar uma tabela inteiramente nova e mover todos os dados de uma só vez.

Uma partição deve ter os mesmos nomes e tipos de dados das colunas da tabela particionada à qual pertence. As modificações nos nomes ou tipos de dados das colunas de uma tabela particionada se propagam automaticamente para todas as partições. As restrições CHECK são herdadas automaticamente por todas as partições, mas uma partição individual pode especificar restrições CHECK adicionais; restrições adicionais, com mesmo nome e condição que na tabela mãe, são mescladas com a restrição das mães. Podem ser especificados valores padrão em separado para cada partição. Mas deve-se observar que o valor padrão de uma partição não é aplicado ao inserir uma tupla através de uma tabela particionada.

As linhas inseridas em uma tabela particionada são roteadas, automaticamente, para a partição correta. Se não houver partição adequada, será relatado erro.

Operações como TRUNCATE, que normalmente afetam a tabela mãe e todas as suas filhas na hierarquia de herança, se propagam em cascata para todas as partições, mas também podem ser realizadas em uma partição individual.

Note que criar uma partição usando PARTITION OF requer a obtenção de um bloqueio ACCESS EXCLUSIVE na tabela particionada mãe. Da mesma forma, excluir uma partição usando DROP TABLE requer a obtenção de um bloqueio ACCESS EXCLUSIVE na tabela mãe. É possível usar ALTER TABLE ATTACH/DETACH PARTITION para realizar estas operações com um bloqueio mais fraco, reduzindo assim a interferência com operações simultâneas na tabela particionada.

A cláusula LIKE especifica uma tabela da qual a nova tabela copia automaticamente todos os nomes de colunas, seus tipos de dados, e suas restrições de não nulo.

Ao contrário de INHERITS, a nova tabela e a tabela original ficam completamente independentes após o término da criação. As alterações na tabela original não serão aplicadas à nova tabela, e não é possível incluir dados da nova tabela em varreduras da tabela original.

Também de forma diferente de INHERITS, as colunas e restrições copiadas por LIKE não são mescladas com colunas e restrições com nomes semelhantes. Se o mesmo nome for especificado explicitamente, ou em outra cláusula LIKE, será relatado erro.

As cláusulas opcionais opção_do_LIKE especificam quais propriedades adicionais da tabela original devem ser copiadas. Especificar INCLUDING copia a propriedade, especificar EXCLUDING omite a propriedade. O padrão é EXCLUDING. Se forem feitas várias especificações para o mesmo tipo de objeto, será usada a última. As opções disponíveis são:

A cláusula LIKE também pode ser usada para copiar definições de colunas de visões, tabelas estrangeiras, ou tipos de dados compostos. As opções que não se aplicam (por exemplo, INCLUDING INDEXES de uma visão) são ignoradas.

Nome opcional para a restrição de coluna ou tabela. Se a restrição for violada, o nome da restrição estará presente nas mensagens de erro, portanto, nomes de restrição como nota deve ser positiva podem ser usados para comunicar informações úteis de restrição às aplicações cliente. (Há necessidade de aspas para especificar nomes de restrição que contêm espaços.) Se o nome da restrição não for especificado, o sistema irá gerar um nome para a restrição.

A coluna não pode conter valores nulos.

Uma restrição marcada com NO INHERIT não será propagada para as tabelas filhas.

A coluna pode conter valores nulos. Este é o padrão.

Esta cláusula é fornecida apenas para manter compatibilidade com bancos de dados SQL fora do padrão. Seu uso é desencorajado em novas aplicações.

A cláusula CHECK especifica uma expressão que produz um resultado booleano, que as linhas novas ou atualizadas devem satisfazer, para que uma operação de inserção ou atualização seja bem-sucedida. Expressões avaliadas como TRUE ou UNKNOWN são bem-sucedidas. Caso qualquer linha de uma operação de inserção ou atualização produza um resultado FALSE é relatado erro, e a inserção ou atualização não altera o banco de dados. Uma restrição de verificação especificada como restrição de coluna deve fazer referência apenas ao valor dessa coluna, enquanto uma expressão que aparece em uma restrição de tabela pode fazer referência a várias colunas.

No momento, as expressões CHECK não podem conter subconsultas, nem se referir a variáveis que não sejam colunas da linha corrente (veja Restrições de verificação). Pode ser referenciada a coluna do sistema tableoid, mas não qualquer outra coluna do sistema.

Uma restrição marcada com NO INHERIT não será propagada para as tabelas filhas.

Quando a tabela possui várias restrições CHECK, elas são testadas para cada linha em ordem alfabética por nome, após a verificação das restrições NOT NULL. (As versões do PostgreSQL anteriores a 9.5 não honravam nenhuma ordem de disparo específica para restrições CHECK.)

A cláusula DEFAULT atribui um valor de dados padrão para a coluna em cuja definição aparece. O valor é qualquer expressão livre de variável (em particular, referências cruzadas a outras colunas na tabela corrente não são permitidas). As subconsultas também não são permitidas. O tipo de dados do valor da expressão do padrão deve corresponder ao tipo de dados da coluna.

A expressão do valor padrão será usada em qualquer operação de inserção que não especifique um valor para a coluna. Se não houver valor padrão para uma coluna, o valor padrão será o valor nulo.

Esta cláusula cria a coluna como uma coluna gerada. A coluna não pode ser escrita e, ao ser lida, será retornado o resultado da expressão especificada.

Quando for especificado VIRTUAL, a coluna será calculada no momento da leitura não ocupando espaço de armazenamento. Quando for especificado STORED, a coluna será calculada no momento da escrita e armazenada em disco. O padrão é VIRTUAL.

A expressão de geração pode se referir a outras colunas da tabela, mas não a outras colunas geradas. Todas as funções e operadores utilizados devem ser imutáveis. Não são permitidas referências a outras tabelas.

Uma coluna virtual gerada não pode ter um tipo de dados definido pelo usuário, e a expressão de geração de uma coluna virtual gerada não deve fazer referência a funções ou tipos de dados definidos pelo usuário, ou seja, só pode usar funções ou tipos de dados nativos. Isto também se aplica indiretamente, como em funções ou tipos de dados que estão na base de operadores ou conversões de tipo de dados. (Esta restrição não existe para colunas geradas e armazenadas.)

Esta cláusula cria a coluna como uma coluna de identidade. Terá uma sequência implícita associada a ela e, em linhas recém-inseridas, a coluna receberá automaticamente os valores dessa sequência. Esta coluna é implicitamente NOT NULL.

As cláusulas ALWAYS e BY DEFAULT determinar como os valores especificados explicitamente pelo usuário são tratados nos comandos INSERT e UPDATE.

No comando INSERT, se for escolhido ALWAYS, o valor especificado pelo usuário só será aceito se o comando INSERT especificar OVERRIDING SYSTEM VALUE. Se for escolhido BY DEFAULT, então o valor especificado pelo usuário terá precedência. Veja o comando INSERT para obter detalhes. (No comando COPY, os valores especificados pelo usuário são sempre usados independentemente dessa configuração.)

Em um comando UPDATE, se for escolhido ALWAYS, qualquer atualização da coluna para qualquer valor diferente do DEFAULT será rejeitada. Se for escolhido BY DEFAULT, a coluna pode ser atualizada normalmente. (Não existe a cláusula OVERRIDING no comando UPDATE.)

A cláusula opcional opções_da_sequência pode ser usada para substituir os parâmetros da sequência. As opções disponíveis incluem as mostradas para CREATE SEQUENCE, mais SEQUENCE NAME nome_da_sequência, LOGGED e UNLOGGED, que permitem selecionar o nome e o nível de persistência da sequência. Sem SEQUENCE NAME, o sistema escolhe um nome não utilizado para a sequência. Sem LOGGED ou UNLOGGED, a sequência terá o mesmo nível de persistência que a tabela.

A restrição UNIQUE especifica que um grupo de uma ou mais colunas de uma tabela pode conter apenas valores únicos. O comportamento de uma restrição de unicidade de tabela é o mesmo de uma restrição de unicidade de coluna, com a capacidade adicional de abranger várias colunas. A restrição, portanto, impõe que quaisquer duas linhas devem diferir em pelo menos uma dessas colunas.

Se for especificada a opção WITHOUT OVERLAPS para a última coluna, esta coluna será verificada quanto a sobreposições em vez de igualdade. Neste caso, as outras colunas da restrição permitirão duplicidades, desde que não se sobreponham na coluna WITHOUT OVERLAPS. (Isto às vezes é chamado de chave temporal, se a coluna for um intervalo de datas ou registros de data e hora, mas o PostgreSQL permite intervalos sobre qualquer tipo de dados base.) Na prática, esta restrição é imposta com uma restrição EXCLUDE em vez de uma restrição UNIQUE. Então, por exemplo, UNIQUE (id, valid_at WITHOUT OVERLAPS) se comporta como EXCLUDE USING GIST (id WITH =, valid_at WITH &&). A colunas WITHOUT OVERLAPS deve ter um tipo de dados intervalo ou multi-intervalo. Não são permitidos intervalos/multi-intervalos vazios. As colunas não-WITHOUT OVERLAPS da restrição podem ser de qualquer tipo de dados que possa ser comparada quanto à igualdade por um índice GiST. Por padrão, apenas tipos de intervalo têm suporte, mas pode-se usar outros tipos de dados adicionando a extensão btree_gist. (que é a forma esperada de usar esta funcionalidade).

Para fins de restrição de unicidade, valores nulos não são considerados iguais, a menos que seja especificado NULLS NOT DISTINCT

Cada restrição de unicidade deve designar um conjunto de colunas que seja diferente do conjunto de colunas designado por qualquer outra restrição de unicidade, ou de chave primária, definida para a tabela. (Caso contrário, as restrições de unicidade redundantes serão descartadas.)

Ao estabelecer uma restrição de unicidade numa hierarquia de partição de vários níveis, todas as colunas da chave de partição da tabela particionada mãe, bem como as de todas as tabelas particionadas filhas, devem ser incluídas na definição da restrição.

A adição de uma restrição de unicidade cria, automaticamente, um índice Árvore-B único na coluna, ou grupo de colunas, usado na restrição. Mas se a restrição incluir uma cláusula WITHOUT OVERLAPS, será usado um índice GiST. O índice criado tem o mesmo nome que a restrição de unicidade.

A cláusula opcional INCLUDE adiciona a este índice uma ou mais colunas que são simplesmente “carga”: a unicidade não é imposta a estas colunas, e o índice não pode ser procurado com base nessas colunas. Entretanto, estas colunas podem ser recuperadas por varredura somente de índice. Note que, embora a restrição não seja imposta às colunas incluídas, ela ainda depende delas. Como consequência, algumas operações nessas colunas (por exemplo, DROP COLUMN) podem causar exclusão em cascata da restrição e do índice.

A restrição PRIMARY KEY especifica que uma coluna, ou colunas, de uma tabela podem conter apenas valores únicos (não duplicados) não nulos. Pode ser especificada apenas uma chave primária para uma tabela, seja como restrição de coluna ou como restrição de tabela.

A restrição de chave primária deve designar um conjunto de colunas diferente do conjunto de colunas designado por qualquer restrição de unicidade definida para a mesma tabela. (Caso contrário, a restrição de unicidade é redundante, sendo por isto descartada.)

A restrição PRIMARY KEY impõe as mesmas restrições nos dados que uma combinação de UNIQUE com NOT NULL. Entretanto, identificar um conjunto de colunas como chave primária também fornece metadados sobre o projeto do esquema, porque uma chave primária implica que outras tabelas podem contar com este conjunto de colunas como um identificador único para as linhas.

Quando colocada em uma tabela particionada, as restrições PRIMARY KEY compartilham as condições descritas anteriormente para a restrição UNIQUE.

Adicionar uma restrição PRIMARY KEY irá criar automaticamente um índice de unicidade Árvore-B na coluna ou grupo de colunas usado na restrição, ou GiST se for especificado WITHOUT OVERLAPS.

A cláusula opcional INCLUDE adiciona a este índice uma ou mais colunas que são simplesmente “carga”: a unicidade não é imposta a estas colunas, e o índice não pode ser pesquisado com base nessas colunas. Entretanto, estas colunas podem ser recuperadas por varredura somente de índice. Note que, embora a restrição não seja imposta às colunas incluídas, ela ainda depende delas. Como consequência, algumas operações nessas colunas (por exemplo, DROP COLUMN) podem causar exclusão em cascata da restrição e do índice.

A cláusula EXCLUDE define uma restrição de exclusão, que garante que se quaisquer duas linhas forem comparadas na(s) coluna(s) ou expressão(ões) especificada(s) usando o(s) operador(es) especificado(s), nem todas estas comparações irão retornar TRUE. Se todos os operadores especificados testarem a igualdade, será equivalente a uma restrição UNIQUE, embora a restrição de unicidade comum seja mais rápida. Entretanto, as restrições de exclusão podem especificar restrições que são mais gerais do que a simples igualdade. Por exemplo, pode-se especificar a restrição de não haver duas linhas na tabela contendo círculos sobrepostos (veja Tipos de dados geométricos) usando o operador &&. Os operadores devem ser comutativos.

As restrições de exclusão são implementadas usando um índice com o mesmo nome da restrição; portanto, cada operador especificado deve ser associado a uma classe de operador apropriada (veja Classes e famílias de operador) para o método de acesso ao índice método_de_índice. Cada elemento_excluído define uma coluna do índice, podendo, opcionalmente, especificar uma ordenação, uma classe de operador, parâmetros da classe de operador e/ou opções de ordenação; conforme descrito detalhadamente em CREATE INDEX.

O método de acesso deve dar suporte a amgettuple (veja Definição da interface do método de acesso a índice); no momento, isto significa que GIN não pode ser usado. Embora seja permitido, há pouco sentido em usar índices de Árvore-B ou hash com restrição de exclusão, porque isto não faz nada que uma restrição de unicidade comum não faça melhor. Então, na prática o método de acesso sempre será GiST ou SP-GiST.

O predicado permite especificar uma restrição de exclusão em um subconjunto da tabela; internamente isto cria um índice parcial. Note que é necessário usar parênteses em torno do predicado.

Ao estabelecer uma restrição de exclusão para uma hierarquia de partições multinível, todas as colunas da chave de partição da tabela particionada de destino, bem como as de todas as suas tabelas particionadas descendentes, devem ser incluídas na definição da restrição. Além disso, estas colunas devem ser comparadas usando o operador de igualdade. Estas restrições garantem que linhas potencialmente conflitantes coexistam na mesma partição. A restrição também pode se referir a outras colunas que não fazem parte de nenhuma chave de partição, as quais podem ser comparadas usando qualquer operador apropriado.

Estas cláusulas especificam uma restrição de chave estrangeira, que exige que um grupo de uma ou mais colunas da nova tabela contenha apenas valores que correspondam aos valores na(s) coluna(s) referenciada(s) de alguma linha da tabela referenciada. Se for omitida a lista de coluna_referenciada, será utilizada a chave primária da tabela_referenciada Caso contrário, a lista de coluna_referenciada deverá se referir às colunas de uma restrição de chave primária ou de unicidade não postergável, ou a colunas de um índice de unicidade não parcial.

Se a última coluna estiver marcada com PERIOD, ela será tratada de forma especial. Enquanto as colunas não-PERIOD são comparadas para verificar a igualdade (devendo haver pelo menos uma), a coluna PERIOD não é. Em vez disso, a restrição é considerada satisfeita se a tabela referenciada tiver registros correspondentes (com base nas partes não-PERIOD da chave) cujos valores de PERIOD combinados cubram completamente os valores do registro de referência. Em outras palavras, a referência deve ter um referente durante toda a sua duração. Esta coluna deve ser do tipo de dados intervalo ou multi-intervalo. Além disso, a tabela referenciada deve ter uma chave primária ou restrição de unicidade declarada com WITHOUT OVERLAPS. Finalmente, se a chave estrangeira tiver uma especificação PERIOD na definição da coluna (especificação de nome_da_coluna), a coluna_referenciada correspondente, se existir, também deverá ser marcada com PERIOD. Se a cláusula coluna_referenciada for omitida e, portanto, a restrição de chave primária da tabela_referenciada for escolhida, a chave primária deverá ter sua última coluna marcada com WITHOUT OVERLAPS.

Para cada par de colunas de referência e colunas referenciadas, se elas forem de um tipo de dados que permite ordenação, as ordenações deverão ser ambas determinísticas ou ambas iguais. Isto garante que as duas colunas tenham uma noção consistente de igualdade.

O usuário deve ter a permissão REFERENCES na tabela referenciada (na tabela inteira ou nas colunas específicas referenciadas). A adição de uma restrição de chave estrangeira requer um bloqueio SHARE ROW EXCLUSIVE na tabela referenciada. Note que não é possível definir restrições de chave estrangeira entre tabelas temporárias e tabelas permanentes.

Os valores inseridos nas colunas que fazem a referência, são comparados com os valores das colunas referenciadas da tabela referenciada, usando o tipo de correspondência indicado. Existem três tipos de correspondência: MATCH FULL, MATCH PARTIAL, e MATCH SIMPLE (que é o padrão). MATCH FULL não permite que uma coluna de uma chave estrangeira de várias colunas seja nula, a menos que todas as colunas da chave estrangeira sejam nulas; se todas forem nulas, a linha não precisa ter uma correspondência na tabela referenciada. MATCH SIMPLE permite que qualquer uma das colunas de chave estrangeira seja nula; se alguma delas for nula, a linha não precisa ter uma correspondência na tabela referenciada. MATCH PARTIAL ainda não está implementado. (Claro que podem ser aplicadas restrições NOT NULL às colunas que fazem referência para evitar que estes casos aconteçam.)

Além disso, quando os dados nas colunas referenciadas são alterados, certas ações são executadas nos dados nas colunas dessa tabela. A cláusula ON DELETE especifica a ação a ser executada quando uma linha referenciada na tabela referenciada está sendo excluída. Da mesma forma, a cláusula ON UPDATE especifica a ação a ser executada quando uma coluna referenciada na tabela referenciada está sendo atualizada para um novo valor. Se a linha for atualizada, mas a coluna referenciada não for alterada, nenhuma ação será executada. As ações referenciais são executadas como parte do comando de alteração de dados, mesmo que a restrição seja postergada. Existem as seguintes ações possíveis para cada cláusula:

Se as colunas referenciadas forem alteradas com frequência, pode fazer sentido adicionar um índice às colunas que fazem referência, para que as ações referenciais associadas à restrição de chave estrangeira possam ser executadas com mais eficiência.

Controla se a restrição pode ser postergada. Uma restrição que não é postergável será verificada imediatamente após cada comando. A verificação das restrições postergáveis pode ser adiada até o final da transação (usando o comando SET CONSTRAINTS). O padrão é NOT DEFERRABLE. No momento, apenas as restrições UNIQUE, PRIMARY KEY, EXCLUDE, e REFERENCES (chave estrangeira) aceitam esta cláusula. As restrições NOT NULL e CHECK não são postergáveis. Note que as restrições postergáveis não podem ser usadas como árbitros de conflito em um comando INSERT que inclua a cláusula ON CONFLICT DO UPDATE.

Se a restrição for postergável, esta cláusula especifica o momento padrão para verificar a restrição. Se a restrição for INITIALLY IMMEDIATE, ela é verificada após cada instrução. Este é o comportamento padrão. Se a restrição for INITIALLY DEFERRED, ela é verificada apenas no final da transação. O momento de verificação da restrição pode ser alterado com o comando SET CONSTRAINTS.

Quando a restrição é ENFORCED, então o sistema de banco de dados garante que a restrição seja satisfeita, verificando-a em momentos apropriados. (após cada declaração ou ao final da transação, conforme apropriado.). Este é o padrão. Se a restrição for NOT ENFORCED, o sistema de banco de dados não irá verificar a restrição. Cabe então ao código da aplicação garantir que as restrições sejam satisfeitas. O sistema de banco de dados ainda pode assumir que os dados realmente satisfazem a restrição para decisões de otimização, mesmo quando isto não afeta a correção do resultado.

As restrições NOT ENFORCED pode ser útil como documentação caso a verificação da restrição em tempo de execução tenha um custo alto.

No momento, só é compatível com chaves estrangeiras e restrições CHECK.

Esta cláusula opcional especifica o método de acesso à tabela a ser usado para armazenar o conteúdo da nova tabela; o método precisa ser um método de acesso do tipo TABLE. Veja Definição da interface do método de acesso à tabela para obter mais informações. Se esta opção não for especificada, será escolhido o método de acesso à tabela padrão para a nova tabela. Veja default_table_access_method para obter mais informações.

Ao criar uma partição, o método de acesso à tabela será o mesmo da tabela particionada, se estiver definido.

Esta cláusula especifica parâmetros de armazenamento opcionais para a tabela ou índice; veja Parâmetros de armazenamento abaixo para obter mais informações. Para compatibilidade com versões anteriores, a cláusula WITH para uma tabela também pode incluir OIDS=FALSE para especificar que as linhas da nova tabela não devem conter OIDs (identificadores de objeto). OIDS=TRUE não tem mais suporte.

Esta é uma sintaxe compatível com versões anteriores para declarar uma tabela WITHOUT OIDS. A criação de uma tabela WITH OIDS não tem mais suporte.

O comportamento das tabelas temporárias no final do bloco de transação pode ser controlado usando ON COMMIT. As três opções são:

O nome_do_espaço_de_tabelas é o nome do espaço de tabelas no qual a nova tabela será criada. Se não for especificado será consultado default_tablespace, ou temp_tablespaces se a tabela for temporária. Para tabelas particionadas, como nenhum armazenamento é necessário para a tabela em si, o espaço de tabelas especificado substitui default_tablespace como o espaço de tabelas padrão a ser usado para quaisquer partições recém-criadas quando nenhum outro espaço de tabelas for especificado explicitamente.

Esta cláusula permite a seleção do espaço de tabelas onde o índice associado a uma restrição UNIQUE, PRIMARY KEY, ou EXCLUDE vai ser criado. Se não for especificado é consultado default_tablespace, ou temp_tablespaces se a tabela for temporária.