Обсуждение: composite types DROP..CASCADE behaviour - bug or intentional?
Hi, <br /><br />Consider the following on latest sources:<br /><br />postgres=# create type c3 as (y int, z c1);<br />postgres=#create type comptype1 as (elem1 int);<br /><br />postgres=# create type comptype2 as (elem1 int, elem2 comptype1);<br/> postgres=# \d comptype2<br />Composite type "public.comptype2"<br /> Column | Type<br />--------+-----------<br/> elem1 | integer<br /> elem2 | comptype1<br /><br />postgres=# drop type comptype1 cascade;<br/>NOTICE: drop cascades to composite type comptype2 column elem2<br /> postgres=# \d comptype2<br />Compositetype "public.comptype2"<br /> Column | Type<br />--------+---------<br /> elem1 | integer<br /><br />Shouldn'tthe drop cascade have deleted comptype2 itself, instead of just deleting the dependent column? Or this is theexpected intentional behaviour?<br clear="all" /><br />Regards,<br />Nikhils<br />-- <br /><a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/>
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