Re: Uninstall script errors

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 19:42:43
Message-ID: 20060302194243.GA8866@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 02, 2006 at 12:52:05AM -0500, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2006-03-02 19:46:40 Re: PostgreSQL Anniversary Summit, Call for Contributions
Previous Message Bruce Momjian 2006-03-02 19:40:59 Re: [HACKERS] slow information schema with thausand users,