CREATE TRIGGER nome { BEFORE | AFTER } { evento [ OR ... ] } ON tabela [ FOR [ EACH ] { ROW | STATEMENT } ] EXECUTE PROCEDURE nome_da_função ( argumentos )
O comando CREATE TRIGGER cria um gatilho. O gatilho fica associado à tabela especificada e executa a função especificada nome_da_função quando ocorrem determinados eventos. [1] [2] [3]
O gatilho pode ser especificado para disparar antes de tentar realizar a operação na linha (antes das restrições serem verificadas e o comando INSERT, UPDATE ou DELETE ser tentado), ou após a operação estar completa (após as restrições serem verificadas e o comando INSERT, UPDATE ou DELETE ter completado). Se o gatilho for disparado antes do evento, o gatilho pode fazer com que a operação não seja realizada para a linha corrente, ou pode modificar a linha sendo inserida (para as operações de INSERT e UPDATE somente). Se o gatilho for disparado após o evento, todas as mudanças, incluindo a última inserção, atualização ou exclusão, estarão "visíveis" para o gatilho.
Um gatilho que está marcado FOR EACH ROW é chamado uma vez para cada linha que a operação modifica. Por exemplo, um comando DELETE afetando 10 linhas faz com que todos os gatilhos ON DELETE da relação de destino sejam chamados 10 vezes, uma vez para cada linha excluída. Diferentemente, um gatilho que está marcado FOR EACH STATEMENT somente executa uma vez para uma determinada operação, não importando quantas linhas sejam modificadas; em particular, uma operação que não modifica nenhuma linha ainda assim resulta na execução de todos os gatilhos FOR EACH STATEMENT aplicáveis.
Se existirem vários gatilhos do mesmo tipo definidos para o mesmo evento, estes serão disparados na ordem alfabética de seus nomes. [4] [5] [6]
O SELECT não modifica nenhuma linha e, portanto, não é possível criar gatilhos para SELECT. Neste caso as regras e visões são mais apropriadas.
Para obter mais informações sobre gatilhos deve ser consultado o Capítulo 32.
O nome a ser dado ao novo gatilho. Deve ser distinto do nome de qualquer outro gatilho para a mesma tabela.
Determina se a função será chamada antes ou depois do evento.
Um entre INSERT, UPDATE ou DELETE; especifica o evento que dispara o gatilho. Podem ser especificados vários eventos utilizando OR.
O nome (opcionalmente qualificado pelo esquema) da tabela que o gatilho se destina.
Especifica se o procedimento do gatilho deve ser disparado uma vez para cada linha afetada pelo evento do gatilho, ou apenas uma vez por comando SQL. Se não for especificado nenhum dos dois, o padrão é FOR EACH STATEMENT.
Uma função fornecida pelo usuário, declarada como não recebendo nenhum argumento e retornando o tipo trigger, que é executada quando o gatilho dispara.
Uma lista opcional de argumentos, separados por vírgula, a serem fornecidos para a função quando o gatilho for executado. Os argumentos são constantes cadeia de caracteres literais. Também podem ser escritos nomes simples e constantes numéricas, mas serão todos convertidos em cadeias de caracteres. Por favor, verifique na descrição da linguagem de implementação da função de gatilho como os argumentos dos gatilhos são acessados dentro da função; pode ser diferente dos argumentos das funções normais.
Para poder criar um gatilho em uma tabela, o usuário deve possuir o privilégio TRIGGER na tabela.
Nas versões do PostgreSQL anteriores a 7.3 era necessário declarar as funções dos gatilhos como retornando o tipo guardador de lugar opaque, em vez de trigger. Para permitir a carga de cópias de segurança antigas (dump), o comando CREATE TRIGGER aceita funções declaradas como retornando opaque, mas mostra uma mensagem e muda o tipo de dado retornado declarado pela função para trigger.
Para remover um gatilho deve ser utilizado o comando DROP TRIGGER.
O comando CREATE TRIGGER do PostgreSQL implementa um subconjunto do padrão SQL:1999 (O padrão SQL-92 não trata de gatilhos). As seguintes funcionalidades estão faltando:
O padrão SQL:1999 permite aos gatilhos disparar devido a atualização de colunas específicas (por exemplo, AFTER UPDATE OF col1, col2).
O padrão SQL:1999 permite definir outros nomes (aliases) para as linhas e tabelas "OLD" e "NEW" a serem utilizados na definição da ação do gatilho (por exemplo, CREATE TRIGGER ... ON nome_da_tabela REFERENCING OLD ROW AS algum_nome NEW ROW AS outro_nome ...). Uma vez que o PostgreSQL permite que os procedimentos dos gatilhos sejam escritos em qualquer uma das linguagens definidas pelo usuário, o acesso aos dados é tratado na forma específica da linguagem.
O PostgreSQL somente permite para a ação do gatilho a execução de uma função definida pelo usuário. O padrão SQL:1999 permite para a ação do gatilho a execução de vários outros comandos SQL, como CREATE TABLE. Esta limitação é fácil de ser superada: basta criar uma função definida pelo usuário para executar os comandos desejados.
O SQL:1999 especifica que gatilhos múltiplos devem ser disparados na ordem da data de criação. O PostgreSQL usa a ordem dos nomes, que foi julgada ser mais conveniente.
A capacidade de especificar várias ações para um único gatilho utilizando OR é uma extensão do PostgreSQL ao padrão SQL.
[1] |
4.6.6.4 — Gatilhos — O gatilho, embora não seja definido como um componente da tabela base, é um objeto associado a uma única tabela base. O gatilho especifica o evento de gatilho, o momento de ação do gatilho, e uma ou mais ações engatilhadas. O evento de gatilho especifica que ação na tabela base deverá disparar as ações engatilhadas. O evento de gatilho é um entre INSERT, DELETE e UPDATE. O momento de ação do gatilho especifica se a ação do gatilho será efetuada BEFORE (antes) ou AFTER (após) o evento do gatilho. A ação engatilhada é um procedimento SQL ou BEGIN ATOMIC, seguido por uma ou mais <declaração de procedimento SQL> terminada por <ponto-e-vírgula>, seguido por END. (ISO-ANSI Working Draft) Framework (SQL/Framework), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-1:2003 (E) (N. do T.) |
[2] |
Oracle — Introdução aos gatilhos Podem ser escritos gatilhos que disparam sempre que ocorrer uma das seguintes operações: 1) Comandos da DML (INSERT, UPDATE ou DELETE) em uma determinada tabela ou visão, executado por qualquer usuário; 2) Comandos da DDL (principalmente CREATE e ALTER) executado por um determinado esquema/usuário ou por qualquer esquema/usuário no banco de dados; 3) Eventos do banco de dados, como conectar/desconectar, erros ou iniciar/parar. O gatilho armazenado no banco de dados pode incluir comandos SQL e PL/SQL ou Java executados como uma unidade, e pode chamar procedimentos armazenados. Entretanto, os procedimentos e os gatilhos diferem na forma como são chamados. O procedimento é executado explicitamente pelo usuário, aplicativo ou gatilho. Os gatilhos são disparados implicitamente pelo Oracle quando ocorre o evento disparador, não importando qual é o usuário que está conectado ou qual é o aplicativo que está sendo utilizado. Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 (N. do T.) |
[3] |
Oracle — Os gatilhos de banco de dados permitem definir e impor regras de integridade, mas os gatilhos de banco de dados não são a mesma coisa que restrições de integridade. Entre outras coisas, o gatilho de banco de dados não verifica os dados já carregados na tabela. Portanto, é altamente recomendado que o uso do gatilho de banco de dados seja feito somente quando a regra de integridade não puder ser imposta através de restrições de integridade. Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 (N. do T.) |
[4] |
Oracle — Embora os gatilhos de tipos diferentes sejam disparados em uma ordem específica, não há garantia que os gatilhos do mesmo tipo para o mesmo comando sejam disparados em uma ordem específica. Por exemplo, pode ser que os gatilhos BEFORE row para um comando UPDATE nem sempre disparem todos na mesma ordem. Os aplicativos devem ser projetados de forma a não dependerem da ordem de disparo dos vários gatilhos do mesmo tipo. Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 (N. do T.) |
[5] |
SQL Server — Pode ser especificado que um dos gatilhos AFTER associados à tabela seja o primeiro gatilho AFTER, ou o último gatilho AFTER, executado para cada ação disparadora INSERT, DELETE e UPDATE. Os gatilhos AFTER disparados entre o primeiro e o último gatilho são executados em uma ordem não definida. SQL Server 2005 Books Online — Specifying First and Last Triggers (N. do T.) |
[6] |
DB2 — Se os eventos para dois gatilhos ocorrerem simultaneamente (por exemplo, se possuirem o mesmo evento, momento de ativação e tabelas), então o primeiro gatilho criado será o primeiro a executar. DB2 Version 9 for Linux, UNIX, and Windows (N. do T.) |