On dirait que vous obtenez un vidage SQL plutôt qu'un vidage binaire de pg_dump . Cela vous donnerait une grosse pile de SQL avec le schéma (y compris les FK) en haut suivi d'un tas d'INSERT pour recharger les données. Un vidage binaire de pg_dump
vous servirait mieux, il semble que vous ayez besoin d'un peu de configuration supplémentaire pour dire à PhpPgAdmin où pg_dump est. Ensuite, vous alimenteriez ce vidage binaire dans pg_restore et pg_restore reconstruirait tout dans le bon ordre pour éviter les problèmes d'intégrité référentielle (ou, plus précisément, pg_restore restaurerait toutes les données puis ajouterait les contraintes).
PhpPgAdmin semble vouloir travailler avec des vidages SQL simples
plutôt que pg_restore . Je trouve cela difficile à croire mais je ne trouve rien dans la documentation sur l'appel de pg_restore . Si cela est vrai, vous devrez probablement modifier manuellement le vidage SQL et déplacer tous les FK à la fin.
Vous pouvez également essayer d'ajouter SET CONSTRAINTS ALL DEFERRED;
en haut de votre vidage SQL, qui devrait retarder la vérification des contraintes jusqu'à la fin de la transaction, vous voudrez également vous assurer que le bloc entier d'INSERTs est contenu dans une transaction.
Si PhpPgAdmin ne peut vraiment pas invoquer pg_restore alors vous feriez mieux d'utiliser en utilisant pg_dump et pg_restore à la main afin que vous ayez le contrôle nécessaire sur vos procédures de sauvegarde. Désolé, mais tout outil d'administration de base de données qui ne peut pas gérer la sauvegarde d'une base de données avec des FK est pire qu'inutile. J'espère que quelqu'un qui connaît PhpPgAdmin se présentera et nous dira comment utiliser pg_restore avec PhpPgAdmin.
