Re: Option to dump foreign data in pg_dump - Mailing list pgsql-hackers

From vignesh C
Subject Re: Option to dump foreign data in pg_dump
Date
Msg-id CALDaNm1YVaQvyDc49TQ+pHf8TBB_k9YDLpSHiPqv3g==GDSQjA@mail.gmail.com
Whole thread Raw
In response to Re: Option to dump foreign data in pg_dump  (Luis Carril <luis.carril@swarm64.com>)
Responses Re: Option to dump foreign data in pg_dump  (Luis Carril <luis.carril@swarm64.com>)
List pgsql-hackers
On Fri, Nov 29, 2019 at 2:10 PM Luis Carril <luis.carril@swarm64.com> wrote:
>
> Luis,
>
> It seems you've got enough support for this concept, so let's move
> forward with this patch.  There are some comments from Tom about the
> patch; would you like to send an updated version perhaps?
>
> Thanks
>
> Hi,
>
>  I've attached a new version (v6) removing the superfluous JOIN that Tom identified, and not collecting the oids
(avoidingthe query) if the option is not used at all. 
>
> About the testing issues that Tom mentioned:
> I do not see how can we have a pure SQL dummy FDW that tests the functionality. Because the only way to identify if
thedata of a foreign table for the chosen server is dumped is if the COPY statement appears in the output, but if the C
callbacksof the FDW are not implemented, then the SELECT that dumps the data to generate the COPY cannot be executed. 
> Also, to test that the include option chooses only the data of the  specified foreign servers we would need some
negativetesting, i.e. that the COPY statement for the non-desired table does not appear. But I do not find these kind
oftests in the test suite, even for other selective options like --table or --exclude-schema. 
>

Can you have a look at dump with parallel option. Parallel option will
take a lock on table while invoking lockTableForWorker. May be this is
not required for foreign tables.
Thoughts?

Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Add FOREIGN to ALTER TABLE in pg_dump
Next
From: John Naylor
Date:
Subject: Re: benchmarking Flex practices