composite types DROP..CASCADE behaviour - bug or intentional?

Consider the following on latest sources:

postgres=# create type c3 as (y int, z c1);

Oops, please disregard the above copy-paste unwanted sql.

postgres=# create type comptype1 as (elem1 int);

postgres=# create type comptype2 as (elem1 int, elem2 comptype1);
postgres=# \d comptype2
Composite type "public.comptype2"
Column | Type
--------+-----------
elem1 | integer
elem2 | comptype1

postgres=# drop type comptype1 cascade;
NOTICE: drop cascades to composite type comptype2 column elem2
postgres=# \d comptype2
Composite type "public.comptype2"
Column | Type
--------+---------
elem1 | integer

Shouldn't the drop cascade have deleted comptype2 itself, instead of just
deleting the dependent column? Or this is the expected intentional
behaviour?

Regards,
Nikhils
--
http://www.enterprisedb.com

--
http://www.enterprisedb.com

Nikhil Sontakke <nikhil.sontakke@enterprisedb.com> writes:

Shouldn't the drop cascade have deleted comptype2 itself, instead of just
deleting the dependent column? Or this is the expected intentional
behaviour?

In the case of a table it's certainly the desired behavior that only
the column and not the whole table goes away. I don't see why composite
types should act differently.

regards, tom lane