SQLite Forum

DROP VIEW IF EXISTS failure
Login
Your explanation is in error.

DROP TABLE `<name>`

means find the table-like object called `<name>`.  If it cannot be found, report an error; if it is of type TABLE, then drop it; otherwise report that you are using the wrong command because the table-like object with name `<name>` is not a TABLE but rather is of type VIEW (or whatever type that table-like object that was found happens to have).

Similarly the command:

DROP VIEW `<name>`

means find the table-like object called `<name>`.  If it cannot be found, report an error; if it is of type VIEW, then drop it; otherwise report that you are using the wrong command because the table-like object with name `<name>` is not a VIEW but rather is of type TABLE (or whatever type that table-like object that was found happens to have).

When you insert the conditional IF EXISTS you are modifying the "finding" of the in the "base class" of the inheritance tree and saying that instead of reporting that the object `<name>` was not found, just do nothing.  However if a table-like object with name `<name>` is found, then report an error if the object is not of the specific instance type you wanted to drop.

So the translation of `DROP <type> IF EXISTS <name>` is not, as you posit  

```
IF WITHIN <type> EXISTS <name>
   DROP <type> <name>
FI
```

but rather

```
IF WITHIN classof(<type>) EXISTS <name>
   DROP <type> <name>
FI
```


The same applies to the commands DROP INDEX which works on index-like objects, and DROP TRIGGER which works with trigger-like objects.

Presently the set of table-like objects include TABLE's (including VIRTUAL tables) and VIEW's.

The set of index-like objects presently only includes INDEX's.

The set of trigger-like objects presently only includes TRIGGER's.

If a new object called a FUDGYBANGER that was an index-like object so that the set of index-like objects now included FUDGYBANGER's as well and INDEX's, then you would get exactly the same behaviour if you tried to DROP FUDGYBANGER `<name>` but it was an INDEX rather than a FUDGYBANGER.

It is like if your programming language had a delete command where you had to specify the type, and you created a variable called **a** of type mudslinger.  If you then said "delete guacamole a" you would expect to to get an error saying that "a is not a guacamole, it is a mudslinger".  If would not matter whether you said "don't do this if there is no variable named **a** because there is, in fact, a variable called **a** -- you are simply being told that you need to keep better track of the objects you have created.