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.GD9812@tamriel.snowman.net
--
Thanks,
Bernd
