Re: Uninstall script errors - Mailing list pgsql-hackers

From Michael Fuhr
Subject Re: Uninstall script errors
Date
Msg-id 20060302194243.GA8866@winnie.fuhr.org
Whole thread Raw
In response to Re: Uninstall script errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Uninstall script errors
List pgsql-hackers
On Thu, Mar 02, 2006 at 12:52:05AM -0500, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > ...  I started to work on a patch but I wasn't sure how
> > to handle the chicken-and-egg situation of dropping a type and its
> > I/O functions.  Is there any way to do that other than DROP TYPE
> > CASCADE?  Should the uninstall scripts be doing that?
> 
> DROP TYPE CASCADE is probably reasonable; that's the way pg_dump
> handles the problem, anyway.

If the uninstall scripts do DROP TYPE CASCADE then would there be
any reason to keep the drops for support objects?  The cascade would
remove everything at a stroke; without the drops for operators,
functions, etc., the scripts would be much simpler.

My concern with DROP TYPE CASCADE is the effect on objects like
tables with a column of that type.  Are the uninstall scripts
intended to do forced drops, or does the absence of CASCADE in the
scripts imply that they're meant to fail if dependent objects exist?

Would it make sense for DROP TYPE to have some kind of limited
cascade so you could drop a type and its I/O functions at the same
time, but still get an error if other objects depend on the type?

-- 
Michael Fuhr


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: PostgreSQL Anniversary Summit, Call for Contributions
Next
From: Hannu Krosing
Date:
Subject: Re: PostgreSQL Anniversary Summit, Call for Contributions