From: Tom Lane <tgl@sss.pgh.pa.us>
To: mwisnicki@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18836: Cannot import foreign schema under different schema
 name when foreign table uses row types
In-reply-to: <18836-070c3c12d36a1331@postgresql.org>
References: <18836-070c3c12d36a1331@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 07 Mar 2025 21:57:20 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1154375.1741396482.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 07 Mar 2025 20:14:42 -0500
Message-ID: <1154376.1741396482@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1154376.1741396482%40sss.pgh.pa.us>
Precedence: bulk

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-O=
PTIONS-IMPORTING