Re: DROP TYPE/DROP DOMAIN - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: DROP TYPE/DROP DOMAIN
Date
Msg-id 083301c35bba$4b648770$2800a8c0@mars
Whole thread Raw
In response to DROP TYPE/DROP DOMAIN  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Responses Re: DROP TYPE/DROP DOMAIN
List pgsql-hackers
> No, but I wouldn't bet on DROP DOMAIN uniformly saying "domain" either.
> It's the same code as soon as you get below the top-level command
> routine (compare RemoveType and RemoveDomain).
>
> > I can't see any conceivable reason to allow this syntax to work!
> > We are giving zero benefit for a non-zero cost...
>
> I'd state that exactly the other way around: testing for and rejecting
> domains in DROP TYPE will take more code (okay, only a few lines, but
> still more code) and I consider the benefit nil.

But should the CREATE DOMAIN manual page refer to DROP TYPE?  Should DROP
DOMAIN be able to drop a type?  What happens in the future if for some
reason we need to add some special case to dropDomain() and the coder
neglects to add it to dropType()?

The benefit is reduced thinks to worry about when coding AFAIKS.

Chris



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: statement level trigger causes pltcl, plpython SIGSEGV
Next
From: "Christopher Kings-Lynne"
Date:
Subject: Re: Adjustment of spinlock sleep delays