2008/12/11 Rogério Grando <[email protected]>:
>
>> Ola pessoal;
>> > Estamos migrando da versão 7.4 para 8.2 mas estamos tendo vários
>> > obstáculos nessa migração e agora na reta final apareceu outro
>> > problema... anteriormente fazia-mos uma transação da seguinte forma.
>> > Temos 2 tabelas: pai e filho sendo que a tabela filho possui uma fk
>> > cascade no delete com a pai.
>> > Executo: DELETE pai WHERE co_pai = 1; INSERT INTO pai (co_pai) VALUES
>> > (2); UPDATE filho SET co_pai = 2;
>> > Na versão 7.4 funciona, na 8.2 não, li a documentação e vi que posso
>> > mudar a fk para DEFERRED e devo colocar BEGIN; e COMMIT; para que a FK
>> > seja validada no final da transação, mas para isso teria que alterar
>> > toda minha aplicação.
>> > Teria alguma configuração postgres.conf ou alguma outra forma de estar
>> > mudando esse comportamento para que seja = a do 7.4?
>>> Oi Sebastian, desculpe se não fui claro, mas o meu problema é que no
>>> momento em que excluo o registro da tabela pai já é excluído da tabela
>>> filho, portanto no momento que faço um update na tabela filho com o novo
>>> código do pai o registro filho ja não existe mais, quando eu executava
>>> isso na versão 7.4 a exclusão da fk era feita no final da transação
>>> acabava não fazendo nada pois o registro filho ja havia sido modificado
>>> com o novo código do pai.
>>>
>>
>>       Não é mais fácil primeiro alterar o filho para depois excluir o pai??
>>
>> --
>> Shander Lyrio
>>
>>
> Ola Shander Lyrio;
>
> Com certeza, mas o que me ocorre aqui é que encontramos em uma
> determinada parte do ERP executando dessa forma, então corrigimos essa
> funcionalidade, mas pode ocorrer em outra parte também, e como sempre o
> desenvolvimento não dispõe de muito tempo para varrer toda a aplicação
> eu tava pesando que houvesse alguma configuração que pudesse me ajudar.
>
>


isso resolve seu problema

-----------
DEFERRABLE
NOT DEFERRABLE

    This controls whether the constraint can be deferred. A constraint
that is not deferrable will be checked immediately after every
command. Checking of constraints that are deferrable can be postponed
until the end of the transaction (using the SET CONSTRAINTS command).
NOT DEFERRABLE is the default. Only foreign key constraints currently
accept this clause. All other constraint types are not deferrable.
-------------
referência: http://www.postgresql.org/docs/8.3/interactive/sql-createtable.html
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a