Parece que está obteniendo un volcado de SQL en lugar de un volcado binario de pg_dump . Eso le daría una gran cantidad de SQL con el esquema (incluidos los FK) en la parte superior, seguido de un montón de INSERT para recargar los datos. Un volcado binario de pg_dump
le serviría mejor, parece que necesita un poco de configuración adicional para decirle a PhpPgAdmin dónde pg_dump es. Entonces alimentaría ese volcado binario en pg_restore y pg_restore reconstruiría todo en el orden correcto para evitar problemas de integridad referencial (o, más exactamente, pg_restore restauraría todos los datos y luego agregaría las restricciones).
PhpPgAdmin parece querer trabajar con volcados de SQL simples
en lugar de pg_restore . Encuentro esto difícil de creer, pero no puedo encontrar nada en la documentación sobre la invocación de pg_restore . Si esto es cierto, probablemente tendrá que editar manualmente el volcado de SQL y mover todos los FK al final.
También puede intentar agregar SET CONSTRAINTS ALL DEFERRED;
en la parte superior de su volcado de SQL, eso debería retrasar la verificación de restricciones hasta el final de la transacción, también querrá asegurarse de que todo el bloque de INSERT esté contenido dentro de una transacción.
Si PhpPgAdmin realmente no puede invocar pg_restore entonces es mejor usar usando pg_dump y pg_restore a mano para que tengas el control necesario sobre tus procedimientos de copia de seguridad. Lo sentimos, pero cualquier herramienta de administración de base de datos que no pueda manejar la copia de seguridad de una base de datos con FK es peor que inútil. Con suerte, aparecerá alguien que conozca PhpPgAdmin y nos diga cómo usar pg_restore con PhpPgAdmin.
