Am Donnerstag, dem 21.01.2021 um 15:56 +0100 schrieb Matthias van de Meent: > Hi, > > Recently I was trying to copy some of the data of one database to > another through postgres_fdw, and found that it wouldn't import that > partition through IMPORT FOREIGN SCHEMA, even when I explicitly > specified the name of the table that contained the data in the LIMIT > TO clause. > > I realised the reason is that currently, postgres_fdw explicitly > disallows importing foreign partitions. This is a reasonable default > when importing a whole schema, but if I wanted to explicitly import > one of a partitioned tables' partitions, that would now require me to > manually copy the foreign table's definitions through the use of > CREATE FOREIGN TABLE, which is a hassle and prone to mistakes. >
Hi, I took a look at this patch. Patch applies on current master. Documentation and adjusted regression tests included. Regression tests passes without errors. The patch changes IMPORT FOREIGN SCHEMA to explicitely allow partition child tables in the LIMIT TO clause of the IMPORT FOREIGN SCHEMA command by relaxing the checks introduced with commit [1]. The reason behind [1] are discussed in [2]. So the original behavior this patch wants to address was done intentionally, so what needs to be discussed here is whether we want to relax that a little. One argument for the original behavior since then was that it is cleaner to just automatically import the parent, which allows access to the childs through the foreign table anways and exclude partition childs when querying pg_class. I haven't seen demand for the implemented feature here myself, but i could imagine use cases where just a single child or a set of child tables are candidates. For example, i think it's possible that users can query only specific childs and want them to have imported on another foreign server. [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f49bcd4ef3e9a75de210357a4d9bbe3e004db956 [2] https://www.postgresql.org/message-id/20170309141531.gd9...@tamriel.snowman.net -- Thanks, Bernd
