- other cleanup
- don't need compat.decimal, that approach never panned out. hopefully
outside libs aren't pulling it in, they shouldn't be

to a DBLINK remote database; while the syntax has been present in the
Oracle dialect for some time, up until now it has never been tested.
The syntax has been tested against a sample database linking to itself,
however there's still some uncertainty as to what should be used for the
"owner" when querying the remote database for table information.
Currently, the value of "username" from user_db_links is used to
match the "owner".  [ticket:2619]

to use the cx_Oracle.LOB type when result rows are returned,
so the dialect has been repaired to exclude LONG from
having cx_Oracle.LOB filtering applied.  Also in 0.7.10.
[ticket:2620]

cx_Oracle so that a return value of ``False`` will result
in no call to ``connection.commit()``, hence avoiding
"no transaction" errors.   Two-phase transactions have
now been shown to work in a rudimental fashion with
SQLAlchemy and cx_oracle, however are subject to caveats
observed with the driver; check the documentation
for details.  Also in 0.7.10.
[ticket:2611]

could be lost if the statement were used as a subquery
inside of another statement, as well as other similar
situations.  Among other things, would cause
typing information to be lost when the Oracle/mssql dialects
would apply limit/offset wrappings. [ticket:2603]