From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP TYPE/DROP DOMAIN |
Date: | 2003-08-06 01:30:17 |
Message-ID: | 083301c35bba$4b648770$2800a8c0@mars |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2003-08-06 01:30:46 | Re: logging stuff |
Previous Message | Joe Conway | 2003-08-06 01:28:03 | Re: statement level trigger causes pltcl, plpython SIGSEGV |