| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | gomer94(at)yandex(dot)ru |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #14867: Cascade drop type error |
| Date: | 2017-10-23 16:09:24 |
| Message-ID: | 4421.1508774964@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
gomer94(at)yandex(dot)ru writes:
> CREATE TYPE my_type AS (f1 integer);
> CREATE TYPE my_type_2 AS (f2 my_type);
> CREATE TABLE my_table (c1 my_type_2);
> CREATE VIEW my_view AS SELECT ((C1).f2).f1 FROM my_table;
> DROP TYPE my_type CASCADE;
Cute. Type my_type isn't exposed as a dependency of the view,
because it's only referenced internally in the expression tree
not as a result column type. We can fix that easily enough by
teaching dependency.c to log the result type of a FieldSelect
as a dependency. That results in dropping the whole view, not
just one column:
regression=# DROP TYPE my_type CASCADE;
NOTICE: drop cascades to 2 other objects
DETAIL: drop cascades to composite type my_type_2 column f2
drop cascades to view my_view
DROP TYPE
which is a bit annoying but I think there's no help for it.
We don't have logic that could rip apart the view query and
reconstruct it without the expression for that one column.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-10-23 16:17:26 | Re: BUG #14867: Cascade drop type error |
| Previous Message | gomer94 | 2017-10-23 15:01:18 | BUG #14867: Cascade drop type error |