RE: BUG #15384: dropping views and materialized views

Thanks Tom

I checked the 'DROP ROUTINE' documentation.

There ROUTINE is sort of a generic name for several object kinds.

Something similar for VIEW and MATERIALIZED VIEW would be helpful for my case.

Best regards,
Terence Zekveld
Senior Developer

EOH Roads & Highways
A division of EOH Industrial Technologies (Pty) Ltd
70 Regency Drive, Route 21 Corporate Park, Centurion

Tel: +27 (12) 346 1255 | Mobile: +27 (79) 696 5363
terence(dot)zekveld(at)eoh(dot)com    |    www.eoh.co.za                                                           

Consulting | Technology | Outsourcing

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: 14 September 2018 04:42 PM
To: Terence Zekveld
Cc: Merlin Moncure; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15384: dropping views and materialized views

Terence Zekveld <Terence(dot)Zekveld(at)eoh(dot)com> writes:
>> But either the 1st or the 2nd DROP functions throw an error, either
>> "theschema.theviewname is not a view" or "theschema.theviewname is not a
>> materialized view".
>> I would think these errors are not relevant when using the "IF EXISTS"
>> option, i.e. it should execute both, 'skipping' the one that refers to the
>> incorrect type of view...

We've discussed this before, but the current policy is that IF [NOT]
EXISTS are narrowly read as applying only to object-does-not-exist
or object-already-exists errors. They're not "get out of jail free"
cards. If you start opening that up, you get into all sorts of
squishy questions; for instance, should a permissions failure become
a non-error?

In the particular case of DROP IF EXISTS, there's a good rationale for
treating doesn't-exist specially: the state after the command is the same
whether the object was there or not, so it's reasonable to consider
doesn't-exist as success rather than an error condition. This does not
hold when the problem is there's-an-object-but-it's-the-wrong-type; then,
that object is still blocking creation of a new object by that name.

I think a more reasonable way to attack this would be, not to make IF
EXISTS more permissive, but to have a distinct command type that's
specifically defined as not caring about the relkind, perhaps
DROP RELATION. v11's DROP ROUTINE is a precedent ...

regards, tom lane