> 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.
Will DROP TYPE automatically handle dropping constraints and dependent
columns properly? Will all its messages use the word 'domain' and not
'type'? I can't see any conceivable reason to allow this syntax to work!
We are giving zero benefit for a non-zero cost...
Chris