Grande William, > From: " William Leite Araújo " <[EMAIL PROTECTED]> > Subject: Re: [pgbr-geral] Trigger mirabolante com View: de Oracle para > Postgres > 2008/9/18 Mozart Hasse <[EMAIL PROTECTED]> > > > Explicando melhor: eu preciso fazer, por conta do mesmo comando de origem, > > duas coisas: > > > > * ajustar ponteiros dos registros anterior, atual e posterior. A trigger > > function pode alterar registros (incluindo o registro original) por conta > > da > > operação original, e essas alterações não devem disparar novamente a > > trigger (ou pelo menos devem notar que é uma chamada recursiva e sair sem > > fazer nada); > > Nesse sentido, existe a possibilidade de desabilitar o trigger durante a > execução do mesmo (caso o usuário tenha essa permissão ou o trigger seja > "SECURITY DEFINNER"). Tipo : > ALTER TABLE [tabela] DISABLE TRIGGER xxx; > (... comandos pra fazer as alterações ...) > ALTER TABLE [tabela] ENABLE TRIGGER xxx; > > Não sei dizer se desabilitará para todas as transações (acredito que > não) ou somente para a corrente.
Seria uma opção extrema. Felizmente não precisei apelar para isso. :-) > > * depois de garantir que os ponteiros estão em ordem, eu tenho de disparar > > uma function (recálculo de registros posteriores) uma única vez a cada > > comando 'externo' à trigger, e isso só pode acontecer _depois_ de atualizar > > o registro original. Esta function pode incluir, alterar e excluir > > registros > > por conta da operação original. Essas operações não devem disparar > > novamente a própria function. > > Bom, essa function (por ser apenas uma) pode então iniciar seu > processamento marcando em uma tabela temporária que está em execução para > evitar que ela seja novamente executada, certo? Sim, sim. O problema está em identificar quando chamá-la ou não. > > O desejável seria que as atualizações da function de recálculo se > > aproveitassem da parte de atualização de ponteiros das trigger functions, > > pois há diversos pontos de atualização e a função depende da integridade > > dos ponteiros após cada operação. A replicação dessa regra em cada um dos > > lugares em que a tabela é atualizada tornaria o código horrivelmente > > complicado, absurdamente redundante e radicalmente difícil de manter. > > > > Concordo. Que coisa mais "louca"... (risos) "louca" não: m - i - r - a - b - o - l - a - n - t - e ! > E isso não funciona com o Postgresql, numa tabela temporária? O nome da > tabela temporária pode conter, por exemplo, o ID da transação !? Ah, bom, era isso que eu queria saber: como identificar unicamente o processo que está atualizando a tabela. Na realidade, o ID da transação não me basta, pois a aplicação pode mandar dúzias de UPDATES dentro da *mesma* transação (cada um aplicando as updates da trigger e exigindo recálculos independentes), que não pode ser dividida por restrição imposta pela regra de negócio. Felizmente acabei me entendendo com tabelas temporárias. Acho que não as pesquisei a fundo por causa da compatibilidade com o Postgres 7, mas isso não é mais um impeditivo no nosso caso. Colocando na tabela temporária um contador de nível cuidadosamente incrementado e decrementado, a rotina está fazendo o básico corretamente. Vou tratar de algumas picuinhas como os tipos DATE perdidos no código (que no Oracle significam outra coisa) e ver como isso se comporta com alta concorrência. Muitíssimo obrigado por enquanto, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
