When trying to use "DROP VIEW IF EXISTS x" while a table named "x" exists, the DROP statement raises an "Error: x is not a view".
The documentation says about the "IF EXISTS" clause:
> Do not throw an error if the view does not exist. A notice is issued in this case.
Imho, there shouldn't be an error if the view does not exist regardless of whether or not a table with this name exists. The observed behavior is contrary to the sense of the "IF EXISTS" clause as one would have to check whether a table with the desired name exists before using "DROP VIEW IF EXISTS". But then you could directly check whether or not the view itself exists.
This thread from 2018 illustrates the current state of the discussion:
I still concur this is indeed a bug that should be fixed.
It is hard to find an agreement here. Both alternatives has benefits and disadvantages. Just depends on personal view. One direction is more tolerant behaviour (more user friendly). Second direction is more strict behaviour (developer friendly).
Probably preferences depends if somebody use DROP as an isolated command or not. I use DROP IF EXISTS together with CREATE statement, and for me is natural current design.
DROP TABLE IF EXISTS xxx;
CREATE TABLE xxx;
If the first statement doesn't fail, then the second statement will be successful with very high priority. For me is little bit more intuitive message "cannot to drop some" then "cannot to create some" when first command is DROP, and I have to investigate, why DROP was ignored.
Because I use these statements typically in pair, then I prefer current behaviour. I am not sure what is the best design here, but I don't think so this case is a bug. It is just ambiguous.
