|From:||Luis Carril <luis(dot)carril(at)swarm64(dot)com>|
|To:||Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Daniel Gustafsson <daniel(at)yesql(dot)se>|
|Cc:||vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Option to dump foreign data in pg_dump|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
a new version of the patch with the tests from Daniel (thanks!) and the nitpicks.
I don't feel good about this feature.
pg_dump should not dump any data that are not part of the database
If you restore such a dump, the data will be inserted into the foreign table,
right? Unless someone emptied the remote table first, this will add
duplicated data to that table.
I think that is an unpleasant surprise. I'd expect that if I drop a database
and restore it from a dump, it should be as it was before. This change would
break that assumption.
What are the use cases of a dump with foreign table data?
Unless I misunderstood something there, -1.
This feature is opt-in so if the user makes dumps of a remote server explicitly by other means, then the user would not need to use these option.
But, not all foreign tables are necessarily in a remote server like the ones referenced by the postgres_fdw.
In FDWs like swarm64da, cstore, citus or timescaledb, the foreign tables are part of your database, and one could expect that a dump of the database includes data from these FDWs.
Luis M Carril
|Next Message||Masahiko Sawada||2019-11-12 11:22:58||Re: cost based vacuum (parallel)|
|Previous Message||Amit Kapila||2019-11-12 11:11:07||Re: [HACKERS] Block level parallel vacuum|