Re: AW: Proposal: More flexible backup/restore via pg_dump
В списке pgsql-hackers по дате отправления:
| От | Giles Lean |
|---|---|
| Тема | Re: AW: Proposal: More flexible backup/restore via pg_dump |
| Дата | |
| Msg-id | 5054.962146132@nemeton.com.au обсуждение исходный текст |
| Ответ на | Re: AW: Proposal: More flexible backup/restore via pg_dump (Philip Warner <pjw@rhyme.com.au>) |
| Ответы |
Re: AW: Proposal: More flexible backup/restore via
pg_dump
|
| Список | pgsql-hackers |
> I don't suppose anyone knows of a way of telling if a file handle supports > seek? The traditional method is to call lseek() and see what happens. > Part of the motivation for this utility was to allow DBAs to fix the > ordering at restore time, but otherwise I totally agree. Unfortunately I > don't think the RI checks can be delayed at this stage - can they? The current pg_dump handles the data and then adds the constraints. Otherwise there are "chicken and egg" problems where two tables have mutual RI constraints. Even at the tuple level two tuples can be mutually dependent. Regards, Giles
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера