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 по дате отправления:

Предыдущее
От: Nikhil Sontakke
Дата:
Сообщение: composite types DROP..CASCADE behaviour - bug or intentional?
Следующее
От: "BogDan Vatra"
Дата:
Сообщение: Re: SE-PostgreSQL and row level security