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 |
Date: | 2019-11-12 11:12:16 |
Message-ID: | FRAPR01MB0724270BFED33F488B0B3246E7770@FRAPR01MB0724.DEUPRD01.PROD.OUTLOOK.DE |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
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
being dumped.
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.
Cheers
Luis M Carril
Attachment | Content-Type | Size |
---|---|---|
0001-Support-foreign-data-in-pg_dump-v4.patch | text/x-patch | 13.4 KB |
From | Date | Subject | |
---|---|---|---|
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 |