Re: DROP TYPE/DROP DOMAIN

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: DROP TYPE/DROP DOMAIN
Дата
Msg-id 083301c35bba$4b648770$2800a8c0@mars
обсуждение исходный текст
Ответ на DROP TYPE/DROP DOMAIN  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Ответы Re: DROP TYPE/DROP DOMAIN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: statement level trigger causes pltcl, plpython SIGSEGV
Следующее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Re: Adjustment of spinlock sleep delays