Horton

Thread

Commits

  1. Fix some oversights in expression dependency recording.

  1. BUG #14867: Cascade drop type error

    gomer94@yandex.ru — 2017-10-23T15:01:18Z

    The following bug has been logged on the website:

Bug reference:      14867
Logged by:          Mansur Galiev
Email address:      gomer94@yandex.ru
PostgreSQL version: 10.0
Operating system:   Ubuntu 16.04.3 LTS x64
Description:        

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;

after then my_view still has a column and a type queries of this:

SELECT * FROM pg_views;

shows:

ERROR:  could not open relation with OID 33070

  2. Re: BUG #14867: Cascade drop type error

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-23T16:09:24Z

    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

  3. Re: BUG #14867: Cascade drop type error

    Andres Freund <andres@anarazel.de> — 2017-10-23T16:17:26Z

    On 2017-10-23 12:09:24 -0400, Tom Lane wrote:
> 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 does remind me of patch 0001 in
http://archives.postgresql.org/message-id/20170314224706.nxvtapenky6eom3z%40alap3.anarazel.de

- Andres

  4. Re: BUG #14867: Cascade drop type error

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-23T16:33:52Z

    Andres Freund <andres@anarazel.de> writes:
> On 2017-10-23 12:09:24 -0400, Tom Lane wrote:
>> 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 does remind me of patch 0001 in
> http://archives.postgresql.org/message-id/20170314224706.nxvtapenky6eom3z%40alap3.anarazel.de

It is in the same part of the code, but seems directed at a different
goal (which I disapproved of, IIRC).  But we definitely need the
principle that any type OID appearing in an expression tree needs to
be logged, except in cases where there's necessarily an indirect
dependency (eg, a function or operator's result type doesn't need to
be logged separately).

			regards, tom lane