Deleting custom fields creates a mess if TRIGGER permissions are not in place

If the MySQL database user for CiviCRM does not have "Trigger" permission, the following bug occurs:

1) User deletes an individual custom data field.

2) There is an error message telling them they do not have authority to "Trigger" in MySQL.

At this point if I look at the table structure in MySQL, the custom field has been dropped. BUT, CiviCRM thinks the custom field still exists. so...

3) If the user tries to view or edit ANY contact record, they get an SQL error message related to the attempt by CiviCRM to refer to a field name that no longer exists in the MySQL table.

If I disable the phantom custom field in CiviCRM, the error from step 3 goes away. But, I cannot delete this phantom custom field in CiviCRM because the SQL fails, due to an attempt to drop a column that does not exist.

So I have 2 questions: It seems TRIGGER permission is now required if I have any intention of using custom fields. Is this the case?

How do I clean up these phantom custom fields?