Re: proposal: possibility to read dumped table's name from file
От | Erik Rijkers |
---|---|
Тема | Re: proposal: possibility to read dumped table's name from file |
Дата | |
Msg-id | 32dbe249-8421-f54e-cacf-39c308c59dd9@xs4all.nl обсуждение исходный текст |
Ответ на | Re: proposal: possibility to read dumped table's name from file (Erik Rijkers <er@xs4all.nl>) |
Ответы |
Re: proposal: possibility to read dumped table's name from file
|
Список | pgsql-hackers |
On 10/1/21 6:19 PM, Erik Rijkers wrote: > On 10/1/21 3:19 PM, Daniel Gustafsson wrote: >> >> As has been discussed upthread, this format strikes a compromise wrt >> simplicity >> and doesn't preclude adding a more structured config file in the >> future should > > If you try to dump/restore a foreign file from a file_fdw server, the > restore step will complain and thus leave the returnvalue nonzero. The > foreign table will be there, with complete 'data'. > > A complete runnable exampe is a lot of work; I hope the below bits of > input and output makes the problem clear. Main thing: the pg_restore > contains 2 ERROR lines like: > > pg_restore: error: COPY failed for table "ireise1": ERROR: cannot > insert into foreign table "ireise1" Further testing makes clear that the file_fdw-addressing line include foreign_data goethe was the culprit: it causes a COPY which of course fails in a readonly wrapper like file_fdw. Without that line it works (because I run the restore on the same machine so the underlying file_fdw .txt files are there for testdb2 too) So the issue is not as serious as it seemed. The complaint remaining is only that this could somehow be documented better. I attach a running example (careful, it deletes stuff) of the original ERROR-producing bash (remove the 'include foreign_data' line from the input file to run it without error). thanks, Erik Rijkers
Вложения
В списке pgsql-hackers по дате отправления: