Re: Option to dump foreign data in pg_dump
От | Alvaro Herrera |
---|---|
Тема | Re: Option to dump foreign data in pg_dump |
Дата | |
Msg-id | 20200323204021.GA15147@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Option to dump foreign data in pg_dump (David Steele <david@pgmasters.net>) |
Ответы |
Re: Option to dump foreign data in pg_dump
Re: Option to dump foreign data in pg_dump |
Список | pgsql-hackers |
v8 attached. I modified Luis' v7 a little bit by putting the ftserver acquisition in the main pg_class query instead of adding one separate query for each foreign table. That seems better overall. I don't understand why this code specifically disallows the empty string as an option to --dump-foreign-data. The other pattern-matching options don't do that. This seems to have been added in response to Daniel's review[1], but I don't quite understand the rationale. No other option behaves that way. I'm inclined to remove that, and I have done so in this version. I removed DumpOptions new bool flag. Seems pointless; we can just check that the list is not null, as we do for other such lists. I split out the proposed test in a different commit; there's no consensus that this test is acceptable as-is. Tom proposed a different strategy[2]; if you try to dump a table with a dummy handler, you'll get this: COPY public.ft1 (c1, c2, c3) FROM stdin; pg_dump: error: query failed: ERROR: foreign-data wrapper "dummy" has no handler pg_dump: error: query was: COPY (SELECT c1, c2, c3 FROM public.ft1 ) TO stdout; Maybe what we should do just verify that you do get that error (and no other errors). [1] https://postgr.es/m/E9C5B25C-52E4-49EC-9958-69CD5BD14EDA@yesql.se [2] https://postgr.es/m/8001.1573759651@sss.pgh.pa.us -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: