Bom, antes de responder lembro que num ambiente Corretamente controlado vc Absolutamente não precisaria disto, pois :
a. todo e qualquer código-fonte (INCLUSIVE stored PL/SQLs) deveria estar contido num sistema de Vesrionamento, justamente para controlar as diferentes versões/releases E b. na produção, apenas o DBA e/ou (no máximo) um Analista-chefe, que sabe o que está fazendo, é quem (mediante uma requisição de alteração formal, que MANTÈM um histórico pesquisável!) é quem saem fazendo DDLs de qualquer tipo com esses dois fatores, naturalmente vc já teria um histórico E seria capaz de fazer rollback de qualquer alteração, em tese.... E AINDA vc tem a vantagem de Revisão do Código : por mais perfunctório que seja o review que o DBA/Analista-chefe faz, ao menos algum código terrivelmente ineficiente e/ou malicioso em alto grau ele pega - se vc deixa qquer um sair colocando código no db de produção, salve-se quem puder... Isto posto, a resposta : se realmente o seu ambiente ainda não está otimamente controlado e portanto precisa de coisas do tipo, eu não tenho código pronto para isso mas tenta adaptar o código mostrado em http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:267415465220#4149424900346580446 , que vc deve ser capaz.... Eu IMAGINO que no seu caso vc teria uma tabela pré-criada á semelhança da DBA_SOURCE e no código da tal trigger (que seria BEFORE) aí vc identifica o objeto pelas built-ins tipo ora_dict_obj_xxx , consulta a DBA_SOURCE e copia as linhas da DBA_SOURCE referentes ao objeto que será alterado, penso... A opção de usara DBMS_METADATA também existe mas deve ser testada COM CUIDADO EXTREMO, dada a performance nem sempre brilhante dessa DBMS.... []s Chiappa
