Bom dia, já passei por situação semelhante, e consegui resolver do seguinte modo (não é o mais prático, mas resolveu no meu caso):
Cada consulta (select, insert, update ou delete), é disparada por uma função específica dentro do sistema (na minha aplicação, feita em PHP). Essa função (em PHP), cria uma tabela temporária, onde é inserido o ID do usuário (e os demais campos necessários). No caso de INSERT, DELETE ou UPDATE, uma função é disparada via trigger, que consulta estes valores da tabela temporária, e grava numa tabela de logs específica, jutamente com os dados alterados (que podem ser obtidos por termos específicos das triggers). A mudança mais drástica, seria a criação desta função e a alteração das consultas já existentes. No meu caso, não precisei alterar muitas coisas, pois a aplicação já possuía uma função que fazia isso (precisei apenas adicionar a criação da tabela temp.). Qualquer dúvida, estou a disposição. Atenciosamente, Pedro Cavalheiro Em 12 de maio de 2012 21:57, Flavio Henrique Araque Gurgel < fla...@4linux.com.br> escreveu: > > Bem, se estamos querendo garantir que o usuário logado seja um usuário > > no SGBD e ainda utilizar um pool de conexões, acredito que não dê. Ao > > menos com o implementação de ORM que costumo utilizar, o "Mega amado > > pelo Dutra" Hibernate. Pois o método getConection() neste ORM esta > > marcado como depreciado e a documentação diz que ele será reimplementado > > no futuro. > > > > Então um Set Session ou algo parecido, crio que não funcionaria. Ademais > > sim, é só fazer este tipo de vinculação que você e o Xará comentaram, é > > até o mais usual, mas também perco as garantias dos grants... acho que > > discuti isso uma vez no fim do ano passado, pelos idos de outubro aqui > > na lista... > > > > é só meu ponto de vista. > > O ORM + pool implementado em servidor de aplicação Java funciona assim. > Não dá mesmo, você está com razão. Com qualquer sistema de banco de dados. > Infelizmente você terá que lidar com isso. A implementação de segurança, > políticas de acesso e preparação para auditoria terão de ser gerenciadas > pela sua aplicação. > > []s > > Flavio Henrique A. Gurgel > Consultor e Instrutor 4Linux > Tel: +55-11-2125-4747 > www.4linux.com.br > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
