BUG #18836: Cannot import foreign schema under different schema name when foreign table uses row types

PG Bug reporting form <noreply@postgresql.org> writes:

Assume foreign public schema has tables that use row types from the same
schema, e.g.

CREATE TABLE public.foo();
CREATE TABLE public.bar(foo public.foo);

If I try to import such schema under different local schema:

CREATE SCHEMA server1_foreign;
IMPORT FOREIGN SCHEMA public FROM SERVER server1 INTO server1_foreign;

Then such import will fail due to mismatched schema of rowtype:

[42704] ERROR: type "public.foo" does not exist
Where: importing foreign table "bar"

Yeah, IMPORT FOREIGN SCHEMA has no idea that the tables might have any
interdependencies, so it just imports them in a random order. (Looks
like the order is actually by table name, so that this specific
example is sure to fail, but if you swapped the table names it'd
work.)

The postgres_fdw documentation does disclaim this case working [1]https://www.postgresql.org/docs/devel/postgres-fdw.html#POSTGRES-FDW-OPTIONS-IMPORTING:

If the remote tables to be imported have columns of user-defined
data types, the local server must have compatible types of the
same names.

That is, said types must *already* exist.

In principle postgresImportForeignSchema could be taught to look
at the remote server's pg_depend data and do a topological sort
to ensure the tables are created in a dependency-aware order.
It'd be a lot of work though, and I'm not sure how far one could
move the needle for a sane amount of effort. (That is, is this
specific pattern the only sort of cross-table dependency?
I'm far from sure about that.) At some level this amounts to
re-implementing pg_dump inside postgres_fdw, which is not a task
I care to buy into. But hey, maybe somebody will take an
interest in making it work better.

regards, tom lane

[1]: https://www.postgresql.org/docs/devel/postgres-fdw.html#POSTGRES-FDW-OPTIONS-IMPORTING

On Fri, 7 Mar 2025 at 20:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:

PG Bug reporting form <noreply@postgresql.org> writes:

Assume foreign public schema has tables that use row types from the same
schema, e.g.

CREATE TABLE public.foo();
CREATE TABLE public.bar(foo public.foo);

If I try to import such schema under different local schema:

CREATE SCHEMA server1_foreign;
IMPORT FOREIGN SCHEMA public FROM SERVER server1 INTO server1_foreign;

Then such import will fail due to mismatched schema of rowtype:

[42704] ERROR: type "public.foo" does not exist
Where: importing foreign table "bar"

Yeah, IMPORT FOREIGN SCHEMA has no idea that the tables might have any
interdependencies, so it just imports them in a random order. (Looks
like the order is actually by table name, so that this specific
example is sure to fail, but if you swapped the table names it'd
work.)

Right, that's another issue which could be solved by topological sort.
In the real world I attempted to work around it by importing in stages,

1. IMPORT ... EXCEPT bar ...
2. IMPORT ... LIMIT TO bar ...

But that didn't work because as you say

The postgres_fdw documentation does disclaim this case working [1]:

If the remote tables to be imported have columns of user-defined
data types, the local server must have compatible types of the
same names.

That is, said types must *already* exist.

Except the row types cannot and will not exist in the expected schema.
Which is the problem I'm complaining about.

IMPORT FOREIGN SCHEMA should be smarter and map schemas of imported
types since it knows remote_schema is going to be local_schema after
import.