Dans Postgres, vous pouvez faire beaucoup avec les transactions qui sont annulés à la fin :
BEGIN;
UPDATE foo ...:
INSERT bar ...;
SELECT baz FROM ...;
CREATE TABLE abc...; -- even works for DDL statements
DROP TABLE def...;
ALTER TABLE ghi ...:
ROLLBACK; -- !
Plus d'informations dans le manuel :BEGIN
ROLLBACK
Sachez cependant que certaines choses ne peuvent pas être annulées. Pour les instances, les séquences ne sont pas annulées. Ou des commandes spéciales comme dblink appels.
Et certaines commandes ne peuvent pas être exécutées dans une transaction avec d'autres. Comme CREATE DATABASE ou VACUUM .
En outre, il peut y avoir des effets secondaires avec une charge simultanée, comme des blocages. Peu probable, cependant. Vous pouvez définir le niveau d'isolement des transactions à vos besoins pour exclure tout effet secondaire (au détriment des performances).
Je ne ferais pas cela avec des données sensibles. Le risque de commettre par accident est trop grand. Et laisser les utilisateurs exécuter du code arbitraire est un risque difficilement maîtrisable. Mais pour un environnement de formation, cela devrait suffire.
Sauvegardez-le avec une base de données de modèles . En cas de problème, c'est le moyen le plus rapide de restaurer un état de base. Exemple (regardez le dernier chapitre) :
Tronquer toutes les tables d'une base de données Postgres
Cela peut également être utilisé comme alternative à la force brute :pour fournir une nouvelle base de données vierge pour chaque stagiaire.
