| From: | Luis Carril <luis(dot)carril(at)swarm64(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Option to dump foreign data in pg_dump |
| Date: | 2019-06-28 17:55:52 |
| Message-ID: | FRXPR01MB0182B04505ADB297D3C40EC0E7FC0@FRXPR01MB0182.DEUPRD01.PROD.OUTLOOK.DE |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>Restoring content of FDW table via pg_restore or psql can be dangerous - there I see a risk, and can be nice to allow it only >with some form of safeguard.
>
>I think so important questions is motivation for dumping FDW - a) clonning (has sense for me and it is safe), b) real backup >(requires writeable FDW) - has sense too, but I see a possibility of unwanted problems.
What about providing a list of FDW servers instead of an all or nothing option? In that way the user really has to do a conscious decision to dump the content of the foreign tables for a specific server, this would allow distinction if multiple FDW are being used in the same DB. Also I think it is responsability of the user to know if the FDW that are being used are read-only or not.
Cheers
Luis M Carril
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-06-28 18:42:49 | Re: [HACKERS] Regression tests vs existing users in an installation |
| Previous Message | Tom Lane | 2019-06-28 17:15:04 | Re: Commitfest 2019-07, the first of five* for PostgreSQL 13 |