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

On Fri, 7 Mar 2025 at 20:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> PG Bug reporting form <noreply(at)postgresql(dot)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