Em 18 de novembro de 2015 22:24, José Henrique Beraldo <henriquebera...@gmail.com> escreveu: > > Opa Tiago, boa noite. Desculpe não retornar antes.
Olá José. Descartei o código anterior para diminuir a resposta. No código que você enviou não justifica o uso do campo "tf_confirmacao_trigger_pai_id". Da forma como está, o trigger da tabela filha sempre irá gravar o valor inserido na pk da tabela pai, e tanto "tf_confirmacao_trigger_pai_id" quanto "tf_tb_id" terão os mesmos valores. Eu não entendi qual a motivação ou a regra por detrás de tudo isto, mas parece ser um erro grosseiro de projeto. Seria interessante revisar esta parte do modelo. Mas como provavelmente trata-se de um software legado, nem vamos discutir este ponto pois talvez não seja possível mudar muita coisa - já me deparei muito com casos assim. Sobre o comportamento descrito na versão 7.4 possivelmente era um bug e foi corrigido. Não faz muito sentido o campo auto-incremento recuperar o valor da sequência em NEW antes do registro ser inserido (BEFORE INSERT). Tanto que para fazer funcionar o seu código, inserindo o valor "tf_confirmacao_trigger_pai_id" na tabela filha com o mesmo valor da chave primária da tabela pai, basta alterar o trigger da tabela pai para AFTER INSERT: CREATE TRIGGER tab_pai_tr AFTER INSERT ON qion.tab_pai FOR EACH ROW EXECUTE PROCEDURE public.f_tab_pai(); Outra coisa: a menos que você queira fazer um teste para verificar se o valor é nulo e abortar a transação, utilize RAISE NOTICE ao invés de RAISE EXCEPTION. RAISE NOTICE 'rRecord.tp_id % tp_data %',rRecord.tp_id,rrecord.tp_data; -- TIAGO J. ADAMI _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
