Re: Uninstall script errors

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Uninstall script errors
Date: 2006-03-06 07:07:34
Message-ID: 20060306070733.GA92339@winnie.fuhr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 06, 2006 at 12:06:28AM -0500, Bruce Momjian wrote:
> Is there any progress on this cleanup?

I'm still planning to work on it unless somebody else wants to, but
I was hoping for more feedback on the use of DROP TYPE CASCADE.
That seems to be the only way to remove a type due to the circular
dependency between the type and its I/O functions, but I'm wary of
CASCADE due to its destructive power. Hence my question about
whether the uninstall scripts are intended to do forced drops or
whether they should fail if dependent objects still exist.

Here are some options I'm thinking about:

1. Use DROP TYPE CASCADE and eliminate the drops for operators,
functions, etc., because the cascade will drop them anyway. This
would make the uninstall scripts simpler than they currently are.

2. Use DROP TYPE CASCADE and keep the drops for support objects.
This would result in the fewest number of changes to the current
scripts.

3. Use DROP TYPE CASCADE, keep the drops for support objects, and
wrap all the drops in a transaction. Certain kinds of dependencies
(e.g., an index dependency on an operator class) will cause one of
those drops to fail, aborting the transaction before it reaches
DROP TYPE CASCADE. This would provide some protection against
dropping a type when dependent objects still exist, but it's not
foolproof. An unindexed column might depend only on the type itself,
so none of the drops would fail and that column would be dropped
by the DROP TYPE CASCADE.

4. Wait for a decision about whether DROP TYPE should be modified
to have the ability to revert the type to a shell so the I/O functions
and finally the type itself can be dropped without using CASCADE.
Another possibility, which Tom has already said is "pretty ugly,"
would be a "limited cascade" whereby DROP TYPE would cascade to the
I/O functions but would raise an error if other dependent objects
still exist.

Comments? Other possibilities?

--
Michael Fuhr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Karasik 2006-03-06 09:12:27 Re: implement prepared queries in plperl
Previous Message Simon Riggs 2006-03-06 06:36:31 Re: problem with large maintenance_work_mem settings and