Re: Uninstall script errors

On Mon, Mar 06, 2006 at 12:07:34AM -0700, Michael Fuhr wrote:
> 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.

TBH, I like Tom's idea in conjunction with a 'more destructive' CASCADE.
Having to change the types to shells, then drop the IO, then drop the
type seems like a 'gotcha' and a bunch of needless extra work.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461