-- Die Buchführung der Migrationen heisst jetzt `migrationen`, nicht mehr
-- `supabase_migrations`. Hier wird das alte Schema abgeräumt.
--
-- ═══ Warum das gefahrlos ist ═══
--
-- Die Reihenfolge trägt die ganze Sicherheit:
--
--   1. scripts/migrate.mjs legt `migrationen.schema_migrations` an und
--      übernimmt einmalig alle Einträge aus `supabase_migrations`, falls es
--      die Tabelle gibt und die neue noch leer ist.
--   2. Erst danach sucht er nach ausstehenden Migrationen — und findet diese
--      hier.
--   3. Diese Datei löscht das alte Schema.
--
-- Zum Zeitpunkt von Schritt 3 stehen die Einträge also bereits doppelt. Wer
-- die Datei einzeln und von Hand einspielt, ohne Schritt 1, verliert dagegen
-- die Buchführung — dann hielte der Läufer alle Migrationen für ausstehend.
-- Deshalb: nur über `node scripts/migrate.mjs` einspielen, nie direkt.
--
-- Auf einer frischen Datenbank hat es das Schema nie gegeben; `if exists`
-- macht die Migration dort zu einem Nichts.
--
-- `cascade` statt `restrict`: das Schema enthält ausschliesslich die eine
-- Tabelle, deren Inhalt eine Zeile weiter oben schon übernommen wurde. Ohne
-- cascade bliebe ein leeres Schema stehen, das niemand mehr anfasst.

drop schema if exists supabase_migrations cascade;