Re: composite types DROP..CASCADE behaviour - bug or intentional? - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: composite types DROP..CASCADE behaviour - bug or intentional?
Date
Msg-id a301bfd90902130417j2b9a3af6qf184c84803d707a1@mail.gmail.com
Whole thread Raw
In response to composite types DROP..CASCADE behaviour - bug or intentional?  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Responses Re: composite types DROP..CASCADE behaviour - bug or intentional?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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

pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: composite types DROP..CASCADE behaviour - bug or intentional?
Next
From: "BogDan Vatra"
Date:
Subject: Re: SE-PostgreSQL and row level security