Skip site navigation (1) Skip section navigation (2)

Re: BUG #5857: pg_restore --clean dropping type too soon

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Stuart Bishop" <stuart(at)stuartbishop(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5857: pg_restore --clean dropping type too soon
Date: 2011-01-31 17:53:17
Message-ID: 19317.1296496397@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Stuart Bishop" <stuart(at)stuartbishop(dot)net> writes:
> "pg_restore --clean" appears to have an ordering problem, where a custom
> type is being dropped before some functions that use that custom type as a
> parameter, which fails.

It's always worked that way, and is difficult to avoid because of the
circular dependencies between a type and its I/O functions.  If we were
to suppress the DROP FUNCTION commands for the I/O functions, we could
have a non-cosmetic failure: suppose the functions have been created
in the target DB, but not the type itself?  Then the DROP TYPE CASCADE
wouldn't remove the functions, and we'd have a conflict when the script
tries to create them again.

I don't think anyone's ever felt that it was essential for --clean to
not produce any "no such object" errors, since in general you'd get some
of those anyway unless the target DB exactly matches the source.  Maybe
an appropriate response is to document that this is expected.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: depsteinDate: 2011-02-01 09:55:49
Subject: pg_dump doesn't save altered column information for inherited columns
Previous:From: Ilie, RaduDate: 2011-01-31 15:19:21
Subject: Re: BUG #5849: Stats Collector Frozen - Autovacuum Not Working Anymore

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group