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
