From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP TYPE/DROP DOMAIN |
Date: | 2003-08-04 14:54:39 |
Message-ID: | 26294.1060008879@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> No, a view is not a table. Try putting an index or trigger on it.
> According to that logic, a domain is not a type. Try putting a check
> constraint on it.
But that's an additional feature, not a missing feature.
I think the reason we are restrictive about the comparable cases for
relations (pg_class entries) is that we use pg_class entries for a
number of things that users see as unrelated or only weakly related.
For example, indexes are not tables by any reasonable definition above
the implementation level; sequences are tables only as an artifact of
a particular implementation (which I think we'll someday have to abandon
BTW); composite types surely aren't tables. It would be surprising for
a composite type to be droppable by DROP TABLE. But domains *are*
types, both to the user and to the implementation, and so I see no
surprise factor in allowing DROP TYPE to work on them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2003-08-04 14:57:28 | Re: contrib compilation probs |
Previous Message | Mendola Gaetano | 2003-08-04 14:47:40 | postmaster core [ 2 ] |