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