Попробовал тут восстановить схему, сделанную pg_dump.
Дамп выглядит так: есть файл restore.sql и несколько файлов цифра.dat - по одному на каждую таблицу, видимо.
Запустил из-под админа psql с restore.sql - не работает. Почитал что внутри - пишут мол, пути к файлам данных, лежащих тут же, рядом со скриптом восстановления мы указали как $$PATH$$ - замените сами как-нибудь на правильные перед восстановлением. Т.е. файлы в скрипте поминаются как '$$PATH$$/3009.dat'. Ну, ОК, думаю, ща поменяю.. В результате такое заклинание пришлось мучительно изобретать:
Блин педорасы, ну зачем доллары туда было совать? Мало других символов чтобы переменную выделить если она вообще нужна??
Идём дальше. Просто офигеть - зачем-то его дамп при восстановлении сносит схему public. Закомментировал. Запускаю снова - ругается что нет юзеров, которым должны быть даны права на объекты. Почему-то юзеры вот не забэкапились. Да ещё я овнеру другое имя дал. Фак. Переименовываю овнера в дампе, слава богу он не пересекается с именами объектов. Создаю отсутствующих юзеров. Запускаю снова - данные всё равно не восстанавливаются!
Смотрю как оно эти данные должны читаться:
Для начала не понимаю смысла вставлять загрузку из пустого STDIN. Ну хрен с ним, вроде ничего страшного делать не должно. Но что же с файлами? В измененном скрипте $$PATH$$ уже поменян на реальный полный путь к файлу, файл есть, я его владелец. Хм, _Я_ его владелец. Меняю владельца на постгрес - всё заработало. Ну вот какого хрена не прочитать файл с моими правами?
Вобщем мракобесие какое-то, а не backup/restore. Как люди с этим живут??
> pg_dump делает один sql-файл, либо один файл в их бинарном формате, чего, обычно, достаточно. Как ты получил такое?
Опцией "-Fd", наверное. И вроде бы без "--schema-only"... Точно не скажу - скрипт сгинул вместе с хостом.
> Точнее, зачем так?
Показалось, что это хорошая идея - скрипт отдельно, данные отдельно. Скрипт хотя бы обозримый получается.
> С COPY всё ок, читаешь-то не ты, а демон БД, который работает под юзером postgres.
Да? А в конструкции "COPY config (id, name, value) FROM stdin;" - демон БД будет из своего stdin читать? Не логично. Кстати, нафига они эту команду туда понавставили?
Re:Перипетии восстановления схемы из pg_dump
>файл restore.sql и несколько файлов цифра.dat
Откуда такие сложности?
pg_dump делает один sql-файл, либо один файл в их бинарном формате, чего, обычно, достаточно. Как ты получил такое? Точнее, зачем так?
С COPY всё ок, читаешь-то не ты, а демон БД, который работает под юзером postgres.
Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0