Opa Tiago, boa noite. Desculpe não retornar antes.
O script abaixo, é um exemplo que criei para simular as diferenças de
comportamento. Fiz a correção na Foreign Key da tabela filho para postergar
a verificação e deu certo, como marquei no script abaixo em "vermelho".
O grande problema que tenho no momento, de comportamento diferente, é a
trigger da tabela filho, se precisar recuperar algo na tabela pai no
registro que ainda está para ser confirmado, isso ele retorna NULL, sendo
que o mesmo script no banco 7.4 funciona normalmente.
CREATE TABLE qion.tab_pai (
tp_id BIGINT DEFAULT nextval('qion.tab_pai_id_seq'::regclass) NOT NULL,
tp_descricao VARCHAR(50) NOT NULL,
tp_data DATE,
tp_valor MONEY,
CONSTRAINT tab_pai_pkey PRIMARY KEY(tp_id)
)
WITH (oids = false);
CREATE TABLE qion.tab_filho (
tf_id BIGSERIAL,
tf_tb_id BIGINT NOT NULL,
tf_data DATE,
tf_confirmacao_trigger_pai_id BIGINT,
CONSTRAINT tab_filho_pkey PRIMARY KEY(tf_id),
CONSTRAINT tab_filho_fk FOREIGN KEY (tf_tb_id)
REFERENCES qion.tab_pai(tp_id)
ON DELETE CASCADE
ON UPDATE CASCADE
* DEFERRABLE*
* INITIALLY DEFERRED*
)
WITH (oids = false);
CREATE OR REPLACE FUNCTION public.f_tab_pai (
)
RETURNS trigger AS
$body$
DECLARE
vVariavel INTEGER;
rRecord RECORD;
BEGIN
INSERT INTO qion.tab_filho
(tf_tb_id,tf_data)
VALUES
(NEW.tp_id,
CURRENT_DATE
);
RETURN NEW ;
END ;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;
CREATE TRIGGER tab_pai_tr
BEFORE INSERT
ON qion.tab_pai FOR EACH ROW
EXECUTE PROCEDURE public.f_tab_pai();
CREATE OR REPLACE FUNCTION public.f_tab_filho (
)
RETURNS trigger AS
$body$
DECLARE
rRecord RECORD;
BEGIN
SELECT INTO rRecord tp_id,tp_data FROM qion.tab_pai WHERE
tp_id=NEW.tf_tb_id;
-- Aqui nesse suposto exemplo de resgatar o valor do registro que ainda
não foi confirmado na tabela pai, por alguma
-- necessidade para que essa trigger funcione, o valor que retorna é
NULL, diferentemente dessa mesma estrutura rodando
--em um banco 7.4.30.
--mesmo que essa trigger seja alterada para AFTER, não funciona.
raise exception 'rRecord.tp_id % tp_data
%',rRecord.tp_id,rrecord.tp_data; -- NULL,NULL seria o retorno
NEW.tf_confirmacao_trigger_pai_id=rRecord.tp_id;
RETURN NEW ;
END ;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;
CREATE TRIGGER tab_filho_tr
BEFORE INSERT
ON qion.tab_filho FOR EACH ROW
EXECUTE PROCEDURE public.f_tab_filho();
-----------------------------------------------
Obrigado...
*José Henrique Beraldo*
Tel: 017 3331-7770
Cel: 017 99979-4669
*Linkedin **linkedin.com/in/josehenriqueberaldo
<http://www.linkedin.com/in/josehenriqueberaldo>*
*Twitter @henriqueberaldo*
*Facebook facebook.com/henriqueberaldo
<http://facebook.com/henriqueberaldo>*
*Skype josehenriqueberaldo*
Em 17 de novembro de 2015 22:25, Tiago José Adami <[email protected]>
escreveu:
>
> Em 17/11/2015 8:16 PM, "José Henrique Beraldo" <[email protected]>
> escreveu:
> >
> > Boa noite.
> > Estou fazendo uma manutenção em um banco de dados 7.4 que foi migrado
> para o 9.4, e o comportamento das triggers mudou.
> > O que percebi é que triggers que funcionam no 7.4 se comportam diferente
> na versão 9.5, por exemplo:
> > 1) quando a tabela pai tem uma trigger que escreve na tabela filho, e a
> tabela filho, normalmente tem uma foreign key do pai, ai dá o erro de
> verificação da constraint.
> > Outro problema que ví, é que na trigger before do pai, ele escreve na
> tabela filho, e na tabela filho tem uma trigger after que precisa coletar o
> registro que ainda está em New da tabela pai, e esse registro não é
> encontrado, diferentemente do 7.4.
> > Preciso reescrever ou há alguma coisa que possa fazer?
> > Obrigado.
> >
> Pelo o que entendi, se o disparo "do" trigger (tradução: gatilho) na
> tabela pai for Before Insert, este comportamento é esperado.
>
> A solução que imagino é alterar o trigger para after Insert na tabela pai.
> Poste o código para que eu e os demais colegas da lista possamos visualizar
> uma possível solução, só pela explicação ficou um pouco difícil de
> entender.
>
> Tiago J. Adami
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
