Re: Uninstall script errors

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Uninstall script errors
Дата
Msg-id 20060307160547.GT82989@pervasive.com
обсуждение исходный текст
Ответ на Re: Uninstall script errors  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: Uninstall script errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: PostgreSQL Anniversary Summit, Call for Contributions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Uninstall script errors