Terence Zekveld <Terence.Zekveld@eoh.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