of :class:`.ForeignKeyConstraint` is silently ignored on the MySQL
backend, will be reverted as of 0.9; this keyword will now render again, raising
errors on MySQL as it is not understood - the same behavior will also
apply to the ``initially`` keyword.  In 0.8, the keywords will remain
ignored but a warning is emitted.   Additionally, the ``match`` keyword
now raises a :class:`.CompileError` on 0.9 and emits a warning on 0.8;
this keyword is not only silently ignored by MySQL but also breaks
the ON UPDATE/ON DELETE options.

To use a :class:`.ForeignKeyConstraint`
that does not render or renders differently on MySQL, use a custom
compilation option.  An example of this usage has been added to the
documentation, see :ref:`mysql_foreign_keys`.
[ticket:2721] [ticket:2839]

mssql to ensure that any literal SQL expression values are
rendered directly as literals, instead of as bound parameters,
within a CREATE INDEX statement. [ticket:2742]
- don't need expression_as_ddl(); literal_binds and include_table
take care of this functionality.

Conflicts:
	lib/sqlalchemy/sql/util.py

Conflicts:
	doc/build/index.rst

Hanno Schlichting.  Also in 0.8.3, 0.7.11.
[ticket:2791]

Conflicts:
	doc/build/changelog/changelog_09.rst

- use an isinstance() check, concerned a TypeError might be indiscriminate

Conflicts:
	doc/build/changelog/changelog_09.rst

Currently, one can specify the prefix length for an index
column using 'mysql_length' keyword argument when creating
an Index instance. But in case of composite indexes the
prefix length value is applied only to the last column.

Extend the existing API in way so that 'mysql_length' argument
value can be either:
    - an integer specifying the same prefix length value
      for each column of an index
    - a (column_name --> integer value) mapping specifying
      the prefix length value for each column of an index
      separately

Fixes issue #2704.

:class:`.ForeignKeyConstraint` will not render the ``DEFERRABLE`` keyword
on the MySQL dialect.  For a long time we left this in place because
a non-deferrable foreign key would act very differently than a deferrable
one, but some environments just disable FKs on MySQL, so we'll be less
opinionated here. [ticket:2721]

Conflicts:
	doc/build/changelog/changelog_09.rst

closes [ticket:1552]

- just do a fetchone() here, no need for len() etc.