Re: Option to dump foreign data in pg_dump

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

In response to

Responses

Browse pgsql-hackers by date

  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