1.8 Step | CreateDatabase

Crea il database applicativo (db_name) con owner db_user, in modo reversibile. Vive in src/steps/create_database.rs. Port di create_db_if_missing di lib/postgres.sh.

Qui vive la protezione più importante dell'intero installer.

---

Protezione critica: mai droppare un database preesistente

È la singola riga di comportamento che distingue "installer che pulisce" da "installer che può distruggere i dati di un cliente".

Un database con lo stesso nome che esisteva già può contenere dati reali. L'undo lo droppa solo se lo abbiamo creato noi (PreState::CreatedByUs). Su Preexisting l'undo è rigorosamente NO-OP.

Il ramo è progettato per essere impossibile da sbagliare: il PreState governa il drop, e la chiamata a dropdb è raggiungibile solo nel ramo CreatedByUs. Non esiste percorso di codice che porti a droppare un DB Preexisting.

undo:
  if prestate != CreatedByUs → log "DB preesistente, NON rimosso" e RITORNA
  altrimenti                 → dropdb --if-exists --force

---

Ciclo di vita

Fase	Comportamento
snapshot	il DB esiste già? (SELECT 1 FROM pg_database WHERE datname = ...) → Preexisting/Untracked. È la fonte di verità della protezione
run	Preexisting → skip. Assente → createdb --owner <user> <db>, poi CreatedByUs. dry_run → solo log
undo	solo CreatedByUs → dropdb --if-exists --force (chiude le connessioni attive). Preexisting → NO-OP con log esplicito

---

Perché è testato in modo diretto e ridondante

Questa non è una gentilezza: è la barriera anti-distruzione. I test la blindano da più angoli:

• DB Preexisting → l'undo non produce alcun DROP DATABASE (né alcun createdb);
• DB assente (CreatedByUs) → createdb in run, dropdb in undo;
• DB Preexisting → nessun dropdb nemmeno invocando undo più volte.

Se un domani un refactor rompesse la protezione, questi test fallirebbero subito.

---

Note di design

• --force su dropdb termina le connessioni attive prima di rimuovere (solo per DB nostri).
• Undo best-effort.
• Coordinamento con 1.7 CreateDbRole: questo step gira dopo il ruolo, quindi al rollback il suo undo (drop DB) precede il drop del ruolo che possiede il DB.