No Postgres, você pode fazer muito com transações que são revertidos no final:
BEGIN;
UPDATE foo ...:
INSERT bar ...;
SELECT baz FROM ...;
CREATE TABLE abc...; -- even works for DDL statements
DROP TABLE def...;
ALTER TABLE ghi ...:
ROLLBACK; -- !
Mais no manual:
BEGIN
ROLLBACK
Esteja ciente de que algumas coisas não podem ser revertidas, no entanto. Para instâncias, as sequências não revertem. Ou alguns comandos especiais como dblink chamadas.
E alguns comandos não podem ser executados em uma transação com outros. Como
CREATE DATABASE ou VACUUM . Além disso, pode haver efeitos colaterais com carga simultânea, como deadlocks. Improvável, porém. Você pode definir o nível de isolamento da transação aos seus requisitos para descartar quaisquer efeitos colaterais (com algum custo para o desempenho).
Eu não faria isso com dados sensíveis. O risco de cometer por acidente é muito grande. E permitir que os usuários executem código arbitrário é um risco dificilmente controlável. Mas para um ambiente de treinamento, isso deve ser bom o suficiente.
Faça backup com um banco de dados de modelo . Se algo der errado, essa é a maneira mais rápida de restaurar um estado básico. Exemplo (veja o último capítulo):
Truncar todas as tabelas em um banco de dados Postgres
Isso também pode ser usado como força bruta alternativa :para fornecer um novo banco de dados para cada trainee.
