Have also considered linking column.label() to the "column" itself being
in the result map but this reveals some naming collision problems (that
also seem to be very poorly tested...).   This should be as far as
we want to go right now with [ticket:2932].

using a column key of the form ``<tablename>_<columnname>``
matching that of an aliased column in the text would still not
match at the ORM level, which is ultimately due to a core
column-matching issue.  Additional rules have been added so that the
column ``_label`` is taken into account when working with a
:class:`.TextAsFrom` construct or with literal columns.
[ticket:2932]

would fail if the referred table in a foreign key contained a schema
name.  Pull request courtesy Thomas Farvour. pullreq github:67

constructs would fail if the bind were constructed with a callable,
rather than a direct value.  This prevented ORM expressions
from being rendered with the "literal_binds" compiler flag.

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.