public inbox for [email protected]
help / color / mirror / Atom feedRe: BUG #19407: pg_dump : DROP RULE creates forward references
2+ messages / 2 participants
[nested] [flat]
* Re: BUG #19407: pg_dump : DROP RULE creates forward references
@ 2026-02-13 22:16 Nathan Bossart <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Nathan Bossart @ 2026-02-13 22:16 UTC (permalink / raw)
To: [email protected]; [email protected]
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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #19407: pg_dump : DROP RULE creates forward references
@ 2026-02-14 01:11 Tom Lane <[email protected]>
parent: Nathan Bossart <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2026-02-14 01:11 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: [email protected]; [email protected]
Nathan Bossart <[email protected]> writes:
> 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.
Actually, AFAICS that 2022 thread didn't lead to any changes.
75af0f401f was in response to a pgsql-docs thread in late 2023,
and I guess by that time I'd forgotten the 2022 thread. But
I still stand by what I said in 2022:
>>> So I think mainly what we ought to do here is to adjust the
>>> documentation to make it clearer that --clean is not guaranteed
>>> to work without errors unless the target database has the same
>>> set of objects as the source. --if-exists can reduce the set
>>> of error cases, but not eliminate it. Possibly we should be
>>> more enthusiastic about recommending --create --clean (ie,
>>> drop and recreate the whole database) instead.
I don't think that actually fixing --clean to handle cases like this
without any errors is feasible, at least not without rethinking the
technology pg_dump uses significantly. For example, we couldn't
just issue "CREATE TYPE t ..." ahead of the CREATE OR REPLACE VIEW.
It'd have to be something like "CREATE TYPE IF NOT EXISTS t ..."
(which we don't have, for what are IMO very good reasons).
We could perhaps make it work by replacing --if-exists with
snippets of plpgsql code to test for existence of target objects,
but that would result in a dump that's completely unportable
instead of only somewhat unportable. And it'd be a huge amount
of work considering that "--clean --create" already does the job.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-02-14 01:11 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-13 22:16 Re: BUG #19407: pg_dump : DROP RULE creates forward references Nathan Bossart <[email protected]>
2026-02-14 01:11 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox