the schema target of a :class:`.ForeignKey` will not be changed unless
that schema matches that of the parent table.  That is, if
a table "schema_a.user" has a foreign key to "schema_b.order.id",
the "schema_b" target will be maintained whether or not the
"schema" argument is passed to :meth:`.Table.tometadata`.  However
if a table "schema_a.user" refers to "schema_a.order.id", the presence
of "schema_a" will be updated on both the parent and referred tables.
This is a behavioral change hence isn't likely to be backported to
0.8; it is assumed that the previous behavior is pretty buggy
however and that it's unlikely anyone was relying upon it.

Additionally, a new parameter has been added
:paramref:`.Table.tometadata.referred_schema_fn`.  This refers to a
callable function which will be used to determine the new referred
schema for any :class:`.ForeignKeyConstraint` encountered in the
tometadata operation.  This callable can be used to revert to the
previous behavior or to customize how referred schemas are treated
on a per-constraint basis.  [ticket:2913]

- rework the tests in test.sql.test_metadata, all the "tometadata" tests
now under new class ToMetaDataTest

oriented row lookups were not matching up to the ad-hoc :class:`.ColumnClause`
objects that :class:`.TextAsFrom` generates, thereby making it not
usable as a target in :meth:`.Query.from_statement`.  Also fixed
:meth:`.Query.from_statement` mechanics to not mistake a :class:`.TextAsFrom`
for a :class:`.Select` construct.  This bug is also an 0.9 regression
as the :meth:`.Text.columns` method is called to accommodate the
:paramref:`.text.typemap` argument. [ticket:2932]

applied to :class:`.Constraint` and :class:`.Index` objects.  Based
on a recipe in the wiki, the new feature uses schema-events to set up
names as various schema objects are associated with each other.  The
events then expose a configuration system through a new argument
:paramref:`.MetaData.naming_convention`.  This system allows production
of both simple and custom naming schemes for constraints and indexes
on a per-:class:`.MetaData` basis.  [ticket:2923]

commit 7e65e52c086652de3dd3303c723f98f09af54db8
Author: Mike Bayer <mike_mp@zzzcomputing.com>
Date:   Sat Feb 1 15:09:04 2014 -0500

    - first pass at new naming approach

flag allows a custom op from :meth:`.Operators.op` to be considered
as a "comparison" operator, thus usable for custom
:paramref:`.relationship.primaryjoin` conditions.

such as "literal binds" into a CAST expression.
- Fixed bug whereby binary type would fail in some cases
if used with a "test" dialect, such as a DefaultDialect or other
dialect with no DBAPI.
- Fixed bug where "literal binds" wouldn't work with a bound parameter
that's a binary type.  A similar, but different, issue is fixed
in 0.8.

into the names used by standard functions in :mod:`sqlalchemy.sql.functions`,
such as ``func.coalesce()`` and ``func.max()``.  Using these functions
in ORM attributes and thus producing annotated versions of them could
corrupt the actual function name rendered in the SQL. [ticket:2927]

for the control is a TypeError for the row, as is raised on py3k when
less/greater operators are used on incompatible types

would lead to ``TypeError`` when compared to non-tuple types as it attempted
to apply tuple() to the "other" object unconditionally.  The
full range of Python comparison operators have now been implemented on
:class:`.RowProxy`, using an approach that guarantees a comparison
system that is equivalent to that of a tuple, and the "other" object
is only coerced if it's an instance of RowProxy. [ticket:2924]