"super" instead of hardcoding to "self.type" for the default return
value, the base Comparator was returning other_comparator.type.   It's
not clear what the rationale for this was, though in theory the
base Comparator should possibly even throw an exception if the two
types aren't the same (or of the same affinity?) .
- mysql.SET was broken on this because the bitwise version adds "0"
to the value to force an integer within column_expression, we are doing type_coerces here
now in any case so that there is no type ambiguity for this
operation

with Firebird, so that the values are again rendered inline when
this is selected.  Related to :ticket:`3034`.
fixes #3381

as up-to-date recommendations as possible

out.
- add __backend__ to the dialect suite so that it runs on CI.
- will be 1.0.0b3

DROP TYPE instruction when a plain ``table.drop()`` is called,
assuming the object is not associated directly with a
:class:`.MetaData` object.   In order to accomodate the use case of
an enumerated type shared between multiple tables, the type should
be associated directly with the :class:`.MetaData` object; in this
case the type will only be created at the metadata level, or if
created directly.  The rules for create/drop of
Postgresql enumerated types have been highly reworked in general.
fixes #3319