Re: Uninstall script errors - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Uninstall script errors
Date
Msg-id 200603060506.k2656Si14296@candle.pha.pa.us
Whole thread Raw
In response to Re: Uninstall script errors  (Michael Fuhr <mike@fuhr.org>)
Responses Re: Uninstall script errors
List pgsql-hackers
Is there any progress on this cleanup?

---------------------------------------------------------------------------

Michael Fuhr wrote:
> On Thu, Mar 02, 2006 at 02:49:13PM -0500, Tom Lane wrote:
> > Michael Fuhr <mike@fuhr.org> writes:
> > > 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?
> > 
> > Seems pretty ugly.  Maybe the thing to do is have a command that somehow
> > reverts a type to the "shell" state, whereupon the deletion sequence can
> > be the exact logical inverse of the creation sequence:
> 
> I thought the same thing after the recent commits involving shell
> types and got similarly stuck.
> 
> Do people at least agree that a DROP TYPE that works without CASCADE
> would be desirable?  The rationale is the same as for other DROP
> commands: drop the object if nothing depends on it, else raise an
> error.  That's impossible now because of the circular dependency
> between a type and its I/O functions, which requires the use of
> CASCADE.
> 
> -- 
> Michael Fuhr
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian   http://candle.pha.pa.us SRA OSS, Inc.   http://www.sraoss.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Not so happy with psql's new multiline behavior
Next
From: Simon Riggs
Date:
Subject: Re: problem with large maintenance_work_mem settings and