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

The following bug has been logged on the website:

Bug reference:      18836
Logged by:          Marcin Wisnicki
Email address:      mwisnicki@gmail.com
PostgreSQL version: 16.8
Operating system:   Linux
Description:

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"

Since postgres knows it's importing public into server1_foreign it should do
the mapping on rowtypes within same schema.

Ideally there should also be an option to customize mapping of custom types
but the above IMHO should work out of the box.

I'm aware I can workaround the problem by importing all tables manually with
CREATE FOREIGN TABLE.

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]:

    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.

> 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