There have been a lot of comments on this topic, and I want to add a bit of a voice to make you think about what you are trying to do. A Database program should generally understand that state and purpose of the database. It should generally know what sort of things the names represent, at least when it matters. If we look at what the purpose of statements like DROP VIEW/TABLE IF EXISTS name, it is generally something to run just before creating a new copy of that table or view to reset back to a know state for testing/development or restoring a backup. Such purposes will generally KNOW if a name should have been a table or a view, and if it doesn't match, the erroring out is generally a good thing. Yes, there are cases where perhaps a view was at some point converted to a table, and to roll back we need to know that to delete to the table to make a view instead, but we should know that and use an appropriate script to roll back. Your need to delete something, not knowing if it is a table or a view is a bit unusual (especially in the middle of a longish transaction where throwing the error would be a problem, seems to point to a very unusual case. It can be argued that the current behavior does match the meaning of the statement, in your example above, test DOES exist, it just isn't a view, so if EXISTS is satisfied, and DROP VIEW fails on the wrong type of object. Yes, you could argue that the meaning could be the DROP VIEW IF EXISTS test; could be interpreted as IF VIEW EXISTS, with the VIEW being assumed, but the current implementation doesn't do it that way. Note, that the statement isn't DROP VIEW test ON ERROR IGNORE,(which doesn't exist as a statement) so the error of test being a table that is the target of a DROP VIEW could be reasonably argued can be raised.