Wygląda na to, że otrzymujesz zrzut SQL, a nie zrzut binarny z pg_dump . Dałoby to duży stos SQL ze schematem (w tym FKs) na górze, a następnie kilka INSERTów do ponownego załadowania danych. Zrzut binarny z pg_dump
służyłoby ci lepiej, wygląda na to, że potrzebujesz trochę dodatkowej konfiguracji, aby powiedzieć PhpPgAdmin, gdzie pg_dump jest. Następnie przekażesz ten zrzut binarny do pg_restore i pg_restore odbudowałby wszystko we właściwej kolejności, aby uniknąć problemów z integralnością referencyjną (lub, dokładniej, pg_restore przywróci wszystkie dane, a następnie doda ograniczenia).
PhpPgAdmin wydaje się chcieć pracuj ze zwykłymi zrzutami SQL
zamiast pg_restore . Trudno mi w to uwierzyć, ale nie mogę znaleźć niczego w dokumentacji na temat wywoływania pg_restore . Jeśli to prawda, prawdopodobnie będziesz musiał ręcznie edytować zrzut SQL i przenieść wszystkie FK na koniec.
Możesz także spróbować dodać SET CONSTRAINTS ALL DEFERRED;
na górze twojego zrzutu SQL, co powinno opóźnić sprawdzanie ograniczeń do końca transakcji, powinieneś również upewnić się, że cały blok INSERTów jest zawarty w transakcji.
Jeśli PhpPgAdmin naprawdę nie może wywołać pg_restore wtedy lepiej jest używać pg_dump i pg_restore ręcznie, aby mieć niezbędną kontrolę nad procedurami tworzenia kopii zapasowych. Przepraszamy, ale każde narzędzie administratora bazy danych, które nie radzi sobie z tworzeniem kopii zapasowej bazy danych za pomocą FK, jest gorzej niż bezużyteczne. Mam nadzieję, że pojawi się ktoś, kto zna się na PhpPgAdmin i poinformuje nas, jak używać pg_restore z PHPPgAdmin.
