Dropping table with SQL has strange consequences

[curlette]

If you drop table with %sql, then the internal cleanup that happens if it were dropped with %bql does not happen. In particular, I ran into this bug:

1. Created a table t with %bql without column x.
2. Created population p for t.
3. Dropped p, then dropped t via %sql.
4. Recreated t (same name) that now has column x with %bql.
5. Tried to create p for t modeling column x as nominal. This failed, saying t has no column x (even though now it does).

[riastradh-probcomp]

Generally using %sql should be avoided. Better: Can you explain what you are trying to do in SQL that BQL can't do, so we can teach BQL to do it?

[curlette]

@riastradh-probcomp I think this was more of an issue of unexpected behavior when using %sql rather than %bql, but if we just tell users to not use %sql for anything %bql can do, then the onus is on them to not carelessly use %sql (like I guess I did by mistake).
@fsaad, thoughts?

[riastradh-probcomp]

Not your fault if you were tempted to use %sql for something -- rather, a lazy omission in BQL. We should generally try to remove the temptations to use %sql; it's just sometimes not expedient in the moment.