[pgbr-geral] Duvida em dump
Olá pessoal, boa tarde! Tenho uma base de dados que armazena várias empresa, sendo dividido por uma coluna co_empresa em todas as tabelas. Preciso fazer um backup apenas de uma empresa. Sei que com dump não é possível, por não ter clausula WHERE. “Que bom seria.” Alguém já precisou fazer isso? Versão: Postgres 8.3.20 em Linux: Debian Outro problema, já a algum tempo não estou recebendo os e-mails da lista, é necessário recadastrar? Grato, pela habitual atenção de todos.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Comportamento de fução
Olá pessoal, boa tarde a todos!
Estava fazendo alguns testes e notei um comportamento estranho.
Quando crio uma função e limito o parâmetro de entrada, esta limitação não
funciona.
Crio uma função que recebe varchar(11), mas se eu passar um varchar de 12 ou
mais ele asseita, a mesma coisa para numeric.
Isso pode provocar uma fala indesejada no sistema. Agora terei que validar isso
na função.
Acho que seria interessante não permitir esta situação.
Testes em PostgreSQL versões 8.5.20 e 9.2 em Windows.
CREATE OR REPLACE FUNCTION sp_teste(nvarchar varchar(11))
RETURNS character varying AS
$BODY$
DECLARE
BEGIN
RETURN nvarchar;
END; $BODY$
LANGUAGE plpgsql VOLATILE;
SELECT sp_teste('12345678910111213');
CREATE OR REPLACE FUNCTION sp_teste2(nnumeric numeric(5,2))
RETURNS numeric AS
$BODY$
DECLARE
BEGIN
RETURN nnumeric;
END; $BODY$
LANGUAGE plpgsql VOLATILE;
SELECT * FROM sp_teste2(145214.52234);
Abraço a todos.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Comportamento DISTINCT PostgreSQL 8.3.5 e 9.1
Olá pessoal! Na versão do PostgreSQL 8.3.5 e acho que nas anteriores deve ser igual (não testei) a clausula DISTINCT faz Sort “ordena” o retorno do SELECT com base na primeira coluna, esta funcionalidade não esta escrita na documentação mas ordena, estou fazendo alguns testes na versão 9.1 e esse comportamento mudou, não é feito mais o Sort, essa mudança pode provocar alguns problemas em aplicações que utilizavam essa clausula sem passar ordenação. Se alguém estiver fazendo migração da versão da base verifiquem para não ter problemas futuros. Obs.: DISTINCT ON faz o Sort, e ele sim esta documentado. Abraço a todos.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Comportamento DISTINCT PostgreSQL 8.3.5 e 9.1
Não há garantia de ordenação nem mesmo na versão 8.3.5 (aliás, vê se atualiza esse trem aí pra 8.3.20 porque tem bug a beça já corrigido). O fato de sair ordenado é mera coincidência. Um UPDATE já pode desfazer a ordenação. Imaginei isso por não estar no próprio documento do PostgreSQL. Estou vendo para atualizar para a 9.1 mas ainda estou analisando. Em 8.4 ou superiores existe uma funcionalidade nova chamada synchronize_seqscans que pode ser ligada para imitar o comportamento passado. Mas, mesmo assim, não há garantia. Já precisei fazer isso quando migramos da versão 7.4 para 8.3 só dor de cabeça. Na verdade no caso do Rogério o que mudou foi que apartir da 8.4 as operações de DISTINCT e UNION/INTERSECT/EXCEPT não são executadas através de um processo de ordenação. Segundo a documentação [1] devemos desabilitar o enable_hashagg para que o comportamento antigo seja restabelecido, mas isso é caro em termos de desempenho. Se você quer ordenar, use ORDER BY. Aplicações que se quebram por não fazerem as consultas direito, após a atualização do SGBD, na minha visão, estão quebradas desde o nascimento. De acordo. É isso ai, se vc quer ordenar isso deve estar explicito em seu SQL. Obrigado pela habitual atenção. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvida Modelagem
Olá pessoal, Boa tarde a todos. Gostaria de saber como os grandes sistemas de ERP trabalham com Multi Empresas? Não sei se isso é uma informação confidencial, mas gostaria de ter uma ideia. 1- Código da empresa nas tabelas (mestre) ? 2- Trabalham separando fisicamente as bases, cada empresa sua base? Unificando o que interessa em uma DW por exemplo. Estou fazendo um levantamento empírico do problema, para ter uma ideia de uma boa prática. Obrigado a todos.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvida Modelagem
Obrigado pessoal, ainda estou fazendo alguns levantamento, mas me parece uma boa pratica deixar na mesma base, ainda estou no inicio da analise de negócio, mas já tenho uma base para estudo. Novamente Obrigado a todos. Gostaria de saber como os grandes sistemas de ERP trabalham com Multi Empresas? Não sei se isso é uma informação confidencial, mas gostaria de ter uma ideia. 1- Código da empresa nas tabelas (mestre) ? 2- Trabalham separando fisicamente as bases, cada empresa sua base? Unificando o que interessa em uma DW por exemplo. Estou fazendo um levantamento empírico do problema, para ter uma ideia de uma boa prática. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Mudar tipo de dados.
Olá pessoal, Estou querendo alterar em várias tabelas os tipos de dados de doble precision para numeric, mas tenho muitas dependências de Views e assim preciso apagar as views alterar o tipo e recriar as mesmas. Alguém sabe de um jeito mais fácil de se fazer isso? Utilizo PostgreSQL 8.3.5. Obrigado pela habitual atenção.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problemas com o catálogo do PostgreSQL
Olá pessoal, Estive em umas das palestras do PgBr deste ano “Estatísticas e monitoramento e diagnósticos através do catalogo do PostgreSQL” e expus um problema que havia ocorrido na mesma semana referente a catálogo, demorei um pouco para postar porque estava tentando simular novamente o problema. Informações: SO: Ubuntu Server, mas fiz um teste no Win e também tive o problema, acho que independe do SO. PostgreSQl: 8.3.5 compilado. Echema: Public Encodig UTF8 Quando é executado o passo 4, alterando o tipo do campo, a ligação b.attrelid = a.relfilenode deixa de ser verdadeira, b.attrelid muda de valor. Assim o select passo 5 que é igual ao passo 3 não encontra mais o registro. Fiz algum teste de renomear a coluna e o mesmo não ocorre, aparentemente isso acontece apenas quando altero o tipo de dados. Obs. A mesma situação ocorre na versão 9.1. Não sei se é forma em que consulto o catálogo que está incorreta, e se alguém já passou por esse tipo de problema. Agradeço pela habitual cordialidade que sempre tive na lista. -- 1º CREATE DATABASE rteste WITH OWNER = postgres ENCODING = 'UTF8' TABLESPACE = pg_default CONNECTION LIMIT = -1; -- 2º CREATE TABLE tab_teste ( co_coluna numeric ) WITH ( OIDS=FALSE ); ALTER TABLE tab_teste OWNER TO postgres; -- 3º Encontra tabela e campo SELECT a.relname AS Tabela, b.attname AS Campo FROM pg_class a JOIN pg_attribute b ON b.attrelid = a.relfilenode WHERE a.relname = 'tab_teste' AND b.attname = 'co_coluna'; -- 4º Provoca o problema ALTER TABLE tab_teste ALTER COLUMN co_coluna TYPE double precision; -- 5º Não encontra mais tabela e campo SELECT a.relname AS Tabela, b.attname AS Campo FROM pg_class a JOIN pg_attribute b ON b.attrelid = a.relfilenode WHERE a.relname = 'tab_teste' AND b.attname = 'co_coluna';___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problemas com o catálogo do PostgreSQL
Ola JotaComm, Na mosca, muito obrigado fico te devendo uma cerveja. Obrigado. SELECT a.relname AS Tabela, b.attname AS Campo FROM pg_class a JOIN pg_attribute b ON b.attrelid = a.relfilenode WHERE a.relname = 'tab_teste' AND b.attname = 'co_coluna'; Na verdade sua consulta ao catalogo está incorreta, você deve usar oid de pg_class que é o identificador da tabela com pg_attribute pelo attrelid. SELECT a.relname AS Tabela, b.attname AS Campo FROM pg_class a JOIN pg_attribute b ON b.attrelid = a.oid WHERE a.relname = 'tab_teste' AND b.attname = 'co_coluna'; Se você executar a consulta vai dar o resultado que você espera. O atributo relfilenode refere-se ao arquivo físico no sitema de arquivos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Possível Bug na versão 8.3 do P ostgreSQL
Ao executar os scripts a baixo ocorre o segunte erro: WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. Isso *não* é um bug. Há várias maneiras de derrubar o postgres; e, essa é mais uma delas. UPDATE pg_trigger SET tgdeferrable = TRUE, tginitdeferred = TRUE; Por que você está fazendo isso? Nem todas os gatilhos são postergáveis (aka _deferrable_). Assim, você está definindo como postergáveis os gatilhos que fazem o cascateamento, que por sua vez, está levando a queda do postgres. Talvez seja viável a prevenção de tal cenário mas ... Sugiro que utilize a sintaxe (DEFERRABLE and INITIALLY DEFERRED) para definir se os gatilhos são postergáveis ou não; só mexa no catálogo quando tiver certeza que o que você está fazendo é seguro. Correto Euler sua sugestão matou meu problema (fico te devendo uma cerveja), eu estava mexendo de forma errada na pg_trigger, fiz os testes e funcionou para todas as situações que temos aqui, demorei para responder porque estava executando os testes. Mas com essa solução fiquei com uma duvida, fiz os testes com a contraint (a)DEFERRABLE INITIALLY DEFERRED e (b)INITIALLY DEFERRED, nos dois modos funcionou, fui ler a documentação e ai que fique na duvida. Pelo que eu entendi a opção (a) ficou redundante a opção (b), não entendi a diferença entre as duas. Obrigado attachment: rogeriogrando.vcf___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Possível Bug na versão 8.3 do P ostgreSQL
Euler Taveira de Oliveira escreveu: Talvez seja viável a prevenção de tal cenário mas ... Para aqueles que não acompanham a -hackers, o Marcelo reportou o problema por lá [1] e um patch [2] já foi aplicado ao PostgreSQL (8.0 até 8.4) corrigindo a queda do servidor; ao invés disso, será emitido um erro. Caso precise do patch imediatamente é só pegá-lo em [3]. [1] http://archives.postgresql.org/pgsql-hackers/2009-10/msg01647.php [2] http://archives.postgresql.org/pgsql-committers/2009-10/msg00119.php [3] http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.255r2=1.256 Obrigado a todos, acho que vou acabar adotando as duas soluções, a passada pelo Euler que na minha opinião a mais correta sem mexer no catalogo e a que o Marcelo reportou como prevenção. Nesse caso eu to devendo uma cervejada a todos hehehehe. attachment: rogeriogrando.vcf___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível Bug na versão 8.3 do P ostgreSQL
2009/10/26 Rogério Grando rogeriogra...@planin.com.br: Olá a todos, Estou com a seguinte situação de problema. PostgreSQL 8.3.5 (Ubuntu Server e Win 2003 Server) independe o SO. Ao executar os scripts a baixo ocorre o segunte erro: WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. o que diz o log? Oi Sebastian, O log diz: Aviso: Finalizando a conecxão por causa da queda de outro processo. Detalhe: O postmaster fará o roll back da transação atual e sair, isso porque um outro processo saiu anormalmente e possivelmente corrompeu a memória compartilhada. Um delete Cascade com tres niveis não deveria dar esse tipo de problema mesmo alterando o comportamento da pg_trigger para postergar a validação. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Possível Bug na versão 8.3 do P ostgreSQL
Rogério Grando escreveu: Ao executar os scripts a baixo ocorre o segunte erro: WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. Isso *não* é um bug. Há várias maneiras de derrubar o postgres; e, essa é mais uma delas. OK entendi. UPDATE pg_trigger SET tgdeferrable = TRUE, tginitdeferred = TRUE; Por que você está fazendo isso? Nem todas os gatilhos são postergáveis (aka _deferrable_). Assim, você está definindo como postergáveis os gatilhos que fazem o cascateamento, que por sua vez, está levando a queda do postgres. Talvez seja viável a prevenção de tal cenário mas ... Sugiro que utilize a sintaxe (DEFERRABLE and INITIALLY DEFERRED) para definir se os gatilhos são postergáveis ou não; só mexa no catálogo quando tiver certeza que o que você está fazendo é seguro. Faço isso porque migramos nossa base de 7.4 para 8.3, e deparamos com essa situação onde o delete e insert em uma transação deve seguir a ordem correta sendo na inserção de pai para filho e na exclusão de filho para o pai. O custo para fazer assa alteração na aplicação é muito grande então resolvemos Postergar a validação de todas as triggers que no nosso caso são mais de 2 mil. Não vejo outra forma de resolver essa situação, teremos que mexer na aplicação para ordenar os deletes e inserts. Obrigado Euler, vou analisar melhor a dica da sintaxe (DEFERRABLE and INITIALLY DEFERRED) vou fazer mais alguns testes e posto aqui caso aja alguma mudança. Agradeço a todos pela ajuda, e parabenizo a todos pela PgCon que estava muito boa, deixei até um trocado lá. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Ordem na clausula WHERE
Ola pessoal, sei que alguns otimizadores lê uma consulta filtrando na clausula WHERE de baixo pra cima ou seja validando primeiro a ultima clausula e sim por diante. No Postgres funciona dessa mesma forma? Obrigado ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Instalação Postgres 7.4 e 8.3 no Linux com encoding diferentes.
Obrigado Ribamar, Valeu pela ajuda. :-) Primeiro olá a todos, estou de volta! Tem, veja isso: Tanto você pode criar após uma instalação pelos repositórios, criando um novo clueter: http://ribafs.wordpress.com/2008/04/01/criando-clusters-no-postgresql-83-windows-e-linux/ Como você pode, na instalação pelos fontes, já instalar com encoding latin1: http://postgresql.ribafs.org/instalacao-do-postgresql/2-instalacao-linux/7-postgresql-ubuntu Olá Pessoal, Estou tentando instalar o postgres nas versões 7.4 e 8.3 na mesma maquina (Linux Ubuntu), a diferença entre os dois é que o 7.4 possui encoding Latin1 e 8.3 UTF8. Tem como fazer isso? Obrigado ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Instalação Postgres 7.4 e 8.3 no Linux com encoding diferentes.
Olá Pessoal, Estou tentando instalar o postgres nas versões 7.4 e 8.3 na mesma maquina (Linux Ubuntu), a diferença entre os dois é que o 7.4 possui encoding Latin1 e 8.3 UTF8. Tem como fazer isso? Obrigado ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problema com DISABLE e ENABLE TRIGGER
Ola pessoal; Estou utilizando o Postgres 8.3.5 e estou com problemas para usar o comando DISABLE e ENABLE TRIGGER. Tenho Uma trigger (X) onde de inicio desabilito uma outra trigger (Y), após desabilitar a trigger (Y) fasso um UPDATE na tabela da trigger (Y) e ao final da trigger (X) habilito novamente a trigger (Y). O erro ocorre no momento de habilitar a trigger. ERRO: cannot ALTER TABLE item because it has pending trigger events ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Instalaçao do Postgre 8.3 .5
Boa tarde pessoal, preciso de um help sou novo aki no grupo Estou tentando fazer a instalação do Postgre 8.3.5 e durante a instalação ele me pede uma senha do superuser..qual senha e esta? e algum senha padrao?? Ja tentei todo tipo de senha de usuario do windowsadministrador e nao obtive sucesso Ola Edvaldo; Suponho que você esteja utilizando Windows Vista. Tente desabilitar o controle de conta do usuário (UAC), Painel de Controle\Contas de Usuário\ Ativar ou desativar o Controle de Conta de Usuário, se não funcionar atualize com o ultimo service pack do Vista. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Consultoria
Ola pessoal; Estou precisando de consultoria em PostgreSQL pra poder atualizar da versão 7.4 para 8.2 ou 8.3 caso haja uma solução para o LATIN1 na 8.3 para Windows. Essa consultoria é para nos orientar nessa transição de versão, para que não ocorra surpresas indesejáveis já com o banco em produção no cliente, se alguem tiver interesse ou conheça alguem para essa finalidade, pode me mandar um email rogeriogra...@planin.com.br mailto:rogeriogra...@planin.com.br, preciso também de um orçamento, caso precise de mais informações estou a disposição. Alguns levantamentos já foram feitos e corrigidos tanto na aplicação como no banco de dados, descritos abaixo: a) Mudança do tipo LO; #Removido (dava erro na restauração) b) Funções do postgres utilizadas na aplicação, os parâmetros passados não eram do mesmo tipo que essas funções recebiam, exemplo: lower, to_char, repeat, upper ... foi feito levantamento em toda aplicação e corrigido. c) Funções desenvolvidas pela Planin utilizadas na aplicação onde ocorriam cast implícito tipo co_entidades(float) = ''. d) Funções do tipo void onde havia um return null(não pode mais na versão 8.2). e) Verificado todos os casts para ver se esta comparando tipos diferentes. f) JOINs Implícitos como SELECT * FROM tab1 WHERE co_tabe1 = tab2.co_tab1; Sabemos também que houve uma mudança no comportamento com na validação de Fks, que na versão 7.4 era feita após a transação e agora é feita no momento da alteração do registro. Obrigado a todos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Digest pgbr-geral, volume 22, assunto 34
Oi Emerson isso resolve seu problema --- DEFERRABLE NOT DEFERRABLE Não resolve meu problema, porque teria que mudar o comportamento de todas as Fks no banco, é mais facil ajustar a plicação, a não ser que tenha um parâmetro que altere o comportamento de todas a FKs de uma só vez, algo no postgres.conf. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SET CONSTRAINTS DEFERRED
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. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] SET CONSTRAINTS DEFERRED
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? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SET CONSTRAINTS DEFERRED
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? tenta desabilitar as triggers antes de alterar a pk... -- desabilita as triggers alter table filho disable trigger all; -- faz os updates -- habilita as triggers novamente alter table filho enable trigger all; Sebastian Selau Webber Colombo 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. Tabela pai, co_pai = 1; Tabela filho co_pai =1; Delete pai = 1; (Postgres 8.2 ja apaga da tabela filho) Insert 2 em pai; Update filho co_pai = 2 where co_pai =1; (Postgres 8.2 filho com co_pai = 1 ja não existe mais) Resultado esperado; Tabela pai, co_pai = 2; Tabela filho co_pai =2; ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
