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  (Daniel Gustafsson <daniel@yesql.se>)
Re: Option to dump foreign data in pg_dump  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Additional size of hash table is alway zero for hash aggregates
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: weird hash plan cost, starting with pg10