From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Uninstall script errors |
Date: | 2006-03-02 21:19:05 |
Message-ID: | 20060302211905.GA9618@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 02, 2006 at 02:49:13PM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-03-02 21:32:01 | Re: [HACKERS] Spaces in psql output (Was: FW: PGBuildfarm |
Previous Message | Bruce Momjian | 2006-03-02 20:49:20 | Re: patch fixing the old RETURN NEXT bug |