From: Tom Lane <tgl@sss.pgh.pa.us>
To: gomer94@yandex.ru
cc: pgsql-bugs@postgresql.org
Subject: Re: BUG #14867: Cascade drop type error
In-reply-to: <20171023150118.1477.19174@wrigleys.postgresql.org>
References: <20171023150118.1477.19174@wrigleys.postgresql.org>
Comments: In-reply-to gomer94@yandex.ru
	message dated "Mon, 23 Oct 2017 15:01:18 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4420.1508774964.1@sss.pgh.pa.us>
Date: Mon, 23 Oct 2017 12:09:24 -0400
Message-ID: <4421.1508774964@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

gomer94@yandex.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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs