From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Luis Carril <luis(dot)carril(at)swarm64(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Option to dump foreign data in pg_dump |
Date: | 2020-01-30 04:26:52 |
Message-ID: | CALDaNm1pdQHgp14ppcUkzQ7AQPodEyBCbzbkK6+uETxn0TKpQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 29, 2020 at 2:00 PM Luis Carril <luis(dot)carril(at)swarm64(dot)com> wrote:
>
> Thanks for working on the comments. I noticed one behavior is
> different when --table option is specified. When --table is specified
> the following are not getting dumped:
> CREATE SERVER foreign_server
>
> I felt the above also should be included as part of the dump when
> include-foreign-data option is specified.
>
> Yes, it also happens on master. A dump of a foreign table using --table, which only dumps the table definition, does not include the extension nor the server.
> I guess that the idea behind --table is that the table prerequisites should already exist on the database.
>
> A similar behavior can be reproduced for a non foreign table. If a table is created in a specific schema, dumping only the table with --table does not dump the schema definition.
>
> So I think we do not need to dump the server with the table.
>
Thanks for the clarification, the behavior sounds reasonable to me
unless others have a different opinion on this.
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kasahara Tatsuhito | 2020-01-30 04:30:56 | Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read) |
Previous Message | vignesh C | 2020-01-30 04:24:17 | Re: pg_restore crash when there is a failure before all child process is created |