SET CONSTRAINTS — define o momento de verificação da restrição para a transação corrente
SET CONSTRAINTS { ALL | nome [, ...] }
{ DEFERRED | IMMEDIATE }
O comando SET CONSTRAINTS define o comportamento
de verificação da restrição na transação corrente
[159]
[160].
As restrições IMMEDIATE são verificadas no final
de cada instrução.
As restrições DEFERRED não são verificadas até
que a transação seja efetivada.
Cada restrição tem seu próprio modo IMMEDIATE ou
DEFERRED.
Após a criação, a restrição recebe uma dessas três características:
DEFERRABLE INITIALLY DEFERRED,
DEFERRABLE INITIALLY IMMEDIATE, ou
NOT DEFERRABLE.
A terceira classe é sempre IMMEDIATE, não sendo
afetada pelo comando SET CONSTRAINTS.
As duas primeiras classes iniciam cada transação no modo indicado,
mas seu comportamento pode ser alterado dentro da transação pelo
comando SET CONSTRAINTS.
O comando SET CONSTRAINTS com uma lista de nomes
de restrições altera o modo apenas dessas restrições
(que devem ser todas postergáveis).
Cada nome de restrição pode ser qualificado pelo esquema.
O caminho de procura de esquema corrente será usado para localizar
o primeiro nome correspondente, se o nome do esquema não for
especificado.
O comando SET CONSTRAINTS ALL altera o modo de
todas as restrições postergáveis.
Quando o comando SET CONSTRAINTS altera o modo de
uma restrição de DEFERRED para
IMMEDIATE, o novo modo entra em vigor
retroativamente: quaisquer modificações de dados pendentes que seriam
verificadas no final da transação, são verificadas durante a execução
do comando SET CONSTRAINTS.
Se alguma restrição for violada, o comando
SET CONSTRAINTS irá falhar
(não alterando o modo de restrição).
Assim, o comando SET CONSTRAINTS pode ser usado
para forçar a verificação das restrições num ponto específico de
uma transação.
No momento, apenas as restrições UNIQUE,
PRIMARY KEY, REFERENCES
(chave estrangeira), e EXCLUDE
são afetadas por esta definição.
As restrições NOT NULL e CHECK
são sempre verificadas imediatamente quando uma linha é inserida ou
modificada (e não no final da declaração).
As restrições de unicidade e exclusão que não foram declaradas como
DEFERRABLE, também são verificadas imediatamente.
O disparo de gatilhos declarados como “gatilhos de restrição” também é controlado por esta definição — eles disparam no mesmo momento em que a restrição associada deve ser verificada.
Como o PostgreSQL não exige que os nomes
das restrições sejam únicos no esquema (mas apenas por tabela),
é possível haver mais de uma correspondência para o nome de restrição
especificado.
Neste caso, o comando SET CONSTRAINTS irá atuar
em todas as correspondências.
Para um nome não qualificado pelo esquema, uma vez que uma
correspondência, ou correspondências, forem localizadas em algum
esquema no caminho de procura, os esquemas que aparecem depois no
caminho não são procurados.
Este comando altera apenas o comportamento das restrições da transação corrente. Executar este comando fora de um bloco de transação produz uma advertência e, fora isto, não tem efeito.
Este comando está em conformidade com o comportamento definido pelo
padrão SQL, exceto pela limitação de que, no
PostgreSQL, ele não se aplica às
restrições NOT NULL e CHECK.
Além disso, o PostgreSQL verifica as
restrições de unicidade não postergáveis imediatamente, e não no
final da instrução, como sugere o padrão.
[159]
Use o comando SET CONSTRAINTS para especificar,
para uma transação específica, se uma restrição postergável será
verificada após cada instrução DML
(IMMEDIATE), ou quando a transação for efetivada
(DEFERRED).
Você pode usar este comando para definir o modo para uma lista de
nomes de restrições, ou para todas as restrições.
Oracle 21 – SET CONSTRAINT[S] (N. T.)
[160] Toda restrição é postergável ou não-postergável (deferrable / non-deferrable). Em uma transação SQL, cada restrição tem um modo de restrição; se a restrição é não-postergável, então seu modo de restrição é sempre imediato, caso contrário, é imediato ou postergável. ISO/IEC 9075-2:1999 (E) – 4.17.1 Checking of constraints (N. T.)