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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
