Date: Fri, 13 Feb 2026 16:16:59 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: dominik.hirt@hub28.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19407: pg_dump : DROP RULE creates forward references
Message-ID: <aY-i27nIktxwhAww@nathan>
References: <19407-0c327e0fc912b451@postgresql.org>
 <aY-Q4met3RVF08LP@nathan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aY-Q4met3RVF08LP@nathan>
Archived-At: <https://www.postgresql.org/message-id/aY-i27nIktxwhAww%40nathan>
Precedence: bulk

On Fri, Feb 13, 2026 at 03:00:18PM -0600, Nathan Bossart wrote:
> On Fri, Feb 13, 2026 at 09:02:37AM +0000, PG Bug reporting form wrote:
>> During dump / restore with pg_dump / psql, I encounter a dependency ordering
>> issue that breaks the import when using ON_ERROR_STOP=on.
>> 
>> Problem: pg_dump executes DROP RULE for specific views, forcing them to be
>> recreated before their dependencies (custom types, collations) exist in the
>> dump file, causing import failures.
> 
> I think this is an even simpler reproducer:
> 
> 	create type t as enum ('a', 'b');
> 	create table tt (a t primary key, b text);
> 	create view v as select * from tt group by a;
> 
> Commit d8c05aff56 [0] did some work in this area, but this issue may even
> predate that.  In any case, it seems like pg_dump needs to create the type
> before it creates the dummy view to deal with circular dependencies.

After some further investigation, I found this discussion from 2022 that
mentions the same problem:

    https://postgr.es/m/flat/b43e03eb-3997-700e-c2d4-92c31e4e31ee%40dalibo.com

This led to commit 75af0f401f, which added some clarity to the
documentation for pg_dump's --clean and --if-exists options, but AFAICT we
don't actually say that using --if-exists with --clean is _not_ guaranteed
to prevent all errors due to nonexistent objects.  Perhaps we should add
that information.  I haven't looked into what it would take to actually fix
this issue, but from reading around I get the idea that it might not be
straightforward.

-- 
nathan