Essa me parece uma solução aceitável. Posso inclusive utilizar essa SP para fazer auditoria na estrutura de dados, logando usuario, data, características antigas e novas. Essa procedure poderia receber um parâmetro para saber qual a alteração na tabela: se criar campo, alterar campo ou excluir campo; ou então pensar em 3 SP especializadas, mas acho que haveria muita replicação de código nesta situação.
Obrigado, Artur Sampaio ----- Original Message ----- From: "Evandro Ricardo Silvestre" <[EMAIL PROTECTED]> To: "Comunidade PostgreSQL Brasileira" <[email protected]> Sent: Thursday, June 12, 2008 1:32 PM Subject: Re: [pgbr-geral] Script à prova de falhas. Artur Sampaio wrote: > Na verdade não se trata de resistência. Sou adepto do uso de PL. > Mas realmente não vejo sentido em compilar uma SP só para atualização da > base de clientes. > > Vamos analisar a situação em mais detalhes: > Vários clientes já rodam a aplicação, e fecharemos um novo release com > melhorias e correções. Vamos chamá-la de versão 5, por exemplo. > Alguns clientes ainda rodam a versão 3.. outros rodam a versão 4. > O campo em questão foi criado na versão 4; então para fazer a atualização > alguns clientes deverão criar o novo campo e outros não. Depois que todos > utilizarem a versão 5, o script nunca mais será usado. > Por isso não vejo motivos para a criação de uma SP, que só será usada 1 > única vez, e somente em alguns clientes. > Crie o Script, faça o que tem que fazer e apague-o ao final de tudo! Faça uma SP que vc passa por parametro o tabela, campo e o tipo de dados e a SP verifica e cria. Dessa forma, nem ALTER TABLE vc precisa mandar, pois ele já estará dentro da SP. Evandro _______________________________________________ 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
