Re: composite types DROP..CASCADE behaviour - bug or intentional?
От | Nikhil Sontakke |
---|---|
Тема | Re: composite types DROP..CASCADE behaviour - bug or intentional? |
Дата | |
Msg-id | a301bfd90902130417j2b9a3af6qf184c84803d707a1@mail.gmail.com обсуждение исходный текст |
Ответ на | composite types DROP..CASCADE behaviour - bug or intentional? (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>) |
Ответы |
Re: composite types DROP..CASCADE behaviour - bug or intentional?
|
Список | 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 по дате отправления: