> On 12 Nov 2019, at 12:12, Luis Carril <luis.carril@swarm64.com> wrote:
> a new version of the patch with the tests from Daniel (thanks!) and the nitpicks.
The nitpicks have been addressed. However, it seems that the new file
containing the test FDW seems missing from the new version of the patch. Did
you forget to git add the file?
>> 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
notneed 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
expectthat a dump of the database includes data from these FDWs.
Right, given the deliberate opt-in which is required I don't see much risk of
unpleasant user surprises. There are no doubt foot-guns available with this
feature, as has been discussed upthread, but the current proposal is IMHO
minimizing them.
cheers ./daniel