En Postgres, puede hacer mucho con transacciones que son retrocedidos al final:
BEGIN;
UPDATE foo ...:
INSERT bar ...;
SELECT baz FROM ...;
CREATE TABLE abc...; -- even works for DDL statements
DROP TABLE def...;
ALTER TABLE ghi ...:
ROLLBACK; -- !
Más en el manual:BEGIN
ROLLBACK
Sin embargo, tenga en cuenta que algunas cosas no se pueden deshacer. Para instancias, las secuencias no retroceden. O algunos comandos especiales como dblink llamadas.
Y algunos comandos no se pueden ejecutar en una transacción con otros. Me gusta CREATE DATABASE o VACUUM .
Además, puede haber efectos secundarios con la carga simultánea, como interbloqueos. Sin embargo, es poco probable. Puede configurar el nivel de aislamiento de transacciones a sus requisitos para descartar cualquier efecto secundario (con algún costo para el rendimiento).
Yo no haría esto con datos sensibles. El riesgo de cometerlo por accidente es demasiado grande. Y dejar que los usuarios ejecuten código arbitrario es un riesgo difícilmente controlable. Pero para un entorno de entrenamiento, eso debería ser lo suficientemente bueno.
Haz una copia de seguridad con una base de datos de plantilla . Si algo sale mal, esa es la forma más rápida de restaurar un estado básico. Ejemplo (mira el último capítulo):
Truncando todas las tablas en una base de datos de Postgres
Esto también se puede usar como fuerza bruta alternativa :para proporcionar una nueva base de datos prístina para cada alumno.
