Klingt so, als würden Sie eher einen SQL-Dump als einen Binär-Dump von pg_dump erhalten . Das würde Ihnen einen großen Haufen SQL mit dem Schema (einschließlich FKs) oben geben, gefolgt von einer Reihe von INSERTs, um die Daten neu zu laden. Ein binärer Dump von pg_dump
Ihnen besser dienen würde, sieht es so aus, als ob Sie ein wenig zusätzliche Konfiguration benötigen, um PhpPgAdmin mitzuteilen, wo pg_dump ist ist. Dann würden Sie diesen binären Dump in pg_restore einspeisen und pg_restore würde alles in der richtigen Reihenfolge neu erstellen, um Probleme mit der referenziellen Integrität zu vermeiden (oder genauer gesagt pg_restore würde alle Daten wiederherstellen und dann die Einschränkungen hinzufügen).
PhpPgAdmin scheint das zu wollen mit einfachen SQL-Dumps arbeiten
statt pg_restore . Ich kann das kaum glauben, aber ich kann in der Dokumentation nichts über den Aufruf von pg_restore finden . Wenn dies zutrifft, müssen Sie den SQL-Dump wahrscheinlich manuell bearbeiten und alle FKs an das Ende verschieben.
Sie könnten auch versuchen, SET CONSTRAINTS ALL DEFERRED;
Oben in Ihrem SQL-Dump, das die Prüfung auf Einschränkungen bis zum Ende der Transaktion verzögern sollte, sollten Sie auch sicherstellen, dass der gesamte Block von INSERTs in einer Transaktion enthalten ist.
Wenn PhpPgAdmin pg_restore wirklich nicht aufrufen kann dann verwenden Sie besser pg_dump und pg_restore von Hand, damit Sie die nötige Kontrolle über Ihre Backup-Verfahren haben. Tut mir leid, aber jedes Datenbankverwaltungstool, das keine Datenbank mit FKs sichern kann, ist mehr als nutzlos. Hoffentlich taucht jemand auf, der sich mit PhpPgAdmin auskennt und uns mitteilt, wie man pg_restore verwendet mit PhpPgAdmin.
