Em um certo reino, em um determinado estado ... eu precisava adicionar um gatilho ao modelo no
pgModeler . O que fazer é fácil o suficiente. Mas para adicionar uma função de trigger ... Também é fácil, mas tive que lidar um pouco com os parâmetros oferecidos para preenchimento / seleção na interface.
O pgModeler é uma ferramenta de design de banco de dados muito boa que pode gerar scripts sql para o
PostgreSQL . Detalhes sobre esta ferramenta e seus recursos podem ser encontrados no
site oficial.
Como exemplo, considere um modelo simplificado com uma única tabela.
Adicione uma função ao modelo.
Depois disso, uma janela será aberta com vários parâmetros editáveis com os quais a função será criada. No entanto, alguns campos já serão preenchidos com valores padrão.
Vamos considerar esses parâmetros em mais detalhes.
Eu acho que com os parâmetros
Nome ,
Esquema ,
Proprietário e
Comentário, tudo fica claro - esse é o nome da função, o esquema do banco de dados, o proprietário e o comentário para essa função, respectivamente.
Idioma é o nome do idioma em que a função será implementada. Para ser sincero, nunca tive que escrever funções para o
PostgreSQL em algo que não
fosse o plpgsql . Portanto, foi esse valor para o parâmetro que eu escolhi.
Método de Retorno . Como na função de gatilho não precisamos retornar a tabela nem o conjunto de valores, deixamos
Simple .
Com os parâmetros no bloco
Data Type , em geral, tudo também é simples. Porque Se a função é chamada no gatilho, no campo
Tipo especificamos o
gatilho (o campo
Formato será preenchido automaticamente com o valor do
gatilho ). O campo
Dimensão (o único campo digital não reservado neste bloco) é necessário para indicar a dimensão da matriz do valor retornado. Mas como precisamos apenas de um valor, não de uma matriz, deixamos
0 nesse campo.
Com os demais parâmetros, nem tudo é tão óbvio, pelo menos para mim, porque nunca tive que pensar neles durante a criação usual de funções no
PostgreSQL .
O tipo de função pode assumir um dos três valores:
IMMUTABLE ,
STABLE e
VOLATILE . Na
documentação oficial do
PostgreSQL , você pode descobrir que esses argumentos informam o otimizador de consultas sobre o comportamento da função.
- IMMUTABLE significa que a função não pode modificar o banco de dados e sempre retorna o mesmo resultado para determinados valores dos argumentos.
- STABLE significa que a função não pode modificar o banco de dados e, em uma única varredura de tabela, sempre retorna o mesmo resultado para determinados valores dos argumentos.
- VOLATILE significa que o resultado de uma função pode mudar mesmo dentro de uma única verificação de tabela, portanto, suas chamadas não podem ser otimizadas.
Consequentemente, se a função de acionamento exigir alteração do banco de dados,
IMMUTABLE não
será adequado. Uma função com o parâmetro
STABLE não é adequada para gatilhos
AFTER que desejam ler linhas modificadas pelo comando atual. Permanece
volátil , que não tem os problemas acima. Também será especificado por padrão se nenhum dos argumentos acima for especificado ao criar a função.
A segurança pode assumir um dos dois valores:
SECURITY DEFINER e
SECURITY INVOKER e é responsável pelos direitos de que usuário será chamado.
- DEFINER DE SEGURANÇA significa que a função será executada com os direitos do usuário que a possui, ou seja, aquele que foi listado no proprietário .
- INVOKER DE SEGURANÇA significa que a função será executada com os direitos do usuário que a chamou.
Por padrão, o
SECURITY INVOKER é usado , para que você possa deixá-lo.
O comportamento pode assumir um dos três valores:
STRICT ,
RETORNA NULL NA ENTRADA NULA e
CHAMADO NA ENTRADA NULA e mostra como a função se comportará se houver valores NULL entre seus argumentos.
- VOLTA NULL EM NULL INPUT ou STRICT significa que a função sempre retornará NULL se pelo menos um de seus argumentos for NULL.
- CHAMADO NA ENTRADA NULL significa que a função será chamada como de costume, mesmo que NULL esteja entre seus argumentos.
O padrão é
CHAMADO NA ENTRADA NULA . Portanto, da mesma maneira, você pode deixá-lo.
Linhas retornadas mostra o número de linhas que o planejador esperará. O valor é especificado para funções que retornam conjuntos. Porque nossa função retorna um único valor, deixamos
0 .
Custo de execução define o custo para executar esta função para o planejador. Para
plpgsql , o padrão é
100 . Portanto, indicamos esse valor.
Windown Func. significa que uma função de janela será criada. No nosso caso, porque precisamos de uma função de gatilho, não precisamos especificar esse valor (bem, em geral, eles escrevem na própria documentação que faz sentido especificar esse parâmetro apenas para funções escritas em C).
A prova de vazamento indica que a função está selada, ou seja, que não divulga informações sobre seus argumentos (por exemplo, não exibe o significado em uma mensagem de erro), exceto para retornar um resultado. Porque Como a função acionadora não aceita argumentos, esse parâmetro não precisa ser especificado.
Assim, os parâmetros da função terminaram. O próprio corpo da função pode ser gravado na mesma janela na guia Definição. Prosseguimos para criar o próprio gatilho.
Depois disso, a janela de criação do acionador será exibida.
Considere os parâmetros que podem ser definidos nesta janela.
Com os parâmetros
Nome ,
Alias e
Comentário, tudo fica claro - este é o nome do gatilho, alias e comentário ao gatilho, respectivamente.
Excution mostra como esse gatilho será executado e pode assumir um dos seguintes valores:
ANTES ,
DEPOIS e
INSTEAD OF , o que significa que a função será executada antes, depois ou em vez do evento.
FOR EACH ROW determina se o procedimento de acionamento será acionado uma vez para cada linha. Se não especificado, o parâmetro
FOR EACH STATEMENT será definido, o que determina que o procedimento de acionamento é acionado uma vez para a instrução SQL.
Evento determina quais eventos precisam ser processados nesse gatilho. Você pode especificar vários eventos. Os eventos são dos seguintes tipos:
INSERT ,
UPDATE ,
DELETE e
TRUNCATE . Eles ocorrem quando o comando correspondente com a mesma instrução SQL é chamado.
A restrição indica que um gatilho de restrição será criado. Os gatilhos de restrição são usados para lançar exceções quando restrições são violadas. Você pode ler mais sobre eles na
documentação oficial.
Para um acionador de restrição, você pode especificar
Adiado , que determina o tempo do acionador. Este parâmetro pode assumir um dos seguintes valores:
INICIALMENTE IMEDIATO ou
INICIALMENTE DIFERIDO .
- INICIALMENTE IMEDIATO significa que o gatilho será acionado após cada instrução.
- INICIALMENTE DIFERIDO significa que o gatilho será acionado apenas no final da transação.
Refer. Tabela é o nome da tabela referenciada pela restrição. Usado para restrições de chave estrangeira e permitido apenas para acionadores de restrição.
Condição é uma condição que determina se a função de disparo será executada. Para acionadores
FOR EACH ROW nesse campo, é possível acessar valores antigos e novos por
OLD e
NEW, respectivamente (ou seja, o mesmo que no corpo da função de acionador).
Argumentos - uma lista de argumentos que serão passados para a função de gatilho quando o gatilho for disparado. As constantes de string são passadas como argumentos para a função.
Colunas - podem ser especificadas apenas para eventos
UPDATE . O acionador funcionará apenas se pelo menos uma das colunas especificadas estiver na lista de colunas especificadas em
UPDATE .
Conclusão
Isso, em geral, é tudo. Espero que tenha sido interessante e útil para alguém.
Ao escrever este artigo, foi utilizado o pgModeler versão 0.9.2-alpha,
construído no Windows 7 x64. Ao usar versões mais antigas / mais recentes do pgModeler, são possíveis pequenas diferenças na interface.
O modelo usado no artigo pode ser baixado
aqui .