Re: BUG #19407: pg_dump : DROP RULE creates forward references

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: dominik(dot)hirt(at)hub28(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19407: pg_dump : DROP RULE creates forward references
Date: 2026-02-14 01:11:01
Message-ID: 604338.1771031461@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Nathan Bossart <nathandbossart(at)gmail(dot)com> 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Noah Misch 2026-02-14 05:38:21 Re: BUG #19406: substring(text) fails on valid UTF-8 toasted value in PostgreSQL 15.16
Previous Message Noah Misch 2026-02-14 00:21:13 Re: BUG #19406: substring(text) fails on valid UTF-8 toasted value in PostgreSQL 15.16