an INSERT of NULL + pyodbc; pyodbc requires a special
object be passed in order to persist NULL.  As the :class:`.VARBINARY`
type is now usually the default for :class:`.LargeBinary` due to
:ticket:`3039`, this issue is partially a regression in 1.0.
The pymssql driver appears to be unaffected.
fixes #3464

:func:`.engine_from_config` were not being parsed correctly;
these included ``pool_threadlocal`` and the psycopg2 argument
``use_native_unicode``. fixes #3435
- add legacy_schema_aliasing config parsing for mssql
- move use_native_unicode config arg to the psycopg2 dialect

``legacy_schema_aliasing`` which when set to False will disable a
very old and obsolete behavior, that of the compiler's
attempt to turn all schema-qualified table names into alias names,
to work around old and no longer locatable issues where SQL
server could not parse a multi-part identifier name in all
circumstances.   The behavior prevented more
sophisticated statements from working correctly, including those which
use hints, as well as CRUD statements that embed correlated SELECT
statements.  Rather than continue to repair the feature to work
with more complex statements, it's better to just disable it
as it should no longer be needed for any modern SQL server
version.  The flag defaults to True for the 1.0.x series, leaving
current behavior unchanged for this version series.  In the 1.1
series, it will default to False.  For the 1.0 series,
when not set to either value explicitly, a warning is emitted
when a schema-qualified table is first used in a statement, which
suggests that the flag be set to False for all modern SQL Server
versions.
fixes #3424
fixes #3430

(hence becoming two regressions); reports that
SELECT statements would GROUP BY a label name and fail was misconstrued
that certain backends such as SQL Server should not be emitting
ORDER BY or GROUP BY on a simple label name at all; when in fact,
we had forgotten that 0.9 was already emitting ORDER BY on a simple
label name for all backends, as described in :ref:`migration_1068`,
as 1.0 had rewritten this logic as part of :ticket:`2992`.

In 1.0.2, the bug is fixed both that SQL Server, Firebird and others
will again emit ORDER BY on a simple label name when passed a
:class:`.Label` construct that is expressed in the columns clause,
and no backend will emit GROUP BY on a simple label name in this case,
as even Postgresql can't reliably do GROUP BY on a simple name
in every case.
fixes #3338, fixes #3385

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

See https://github.com/pymssql/pymssql/commit/e7fb15dd29090e1f1bb570842b53aea1ec32d8f0

is the flag that per :ticket:`2992` causes an order by or group by
an expression that's also in the columns clause to be copied by
label, even if referenced as the expression object.   The behavior
for MSSQL is now the old behavior that copies the whole expression
in by default, as MSSQL can be picky on these particularly in
GROUP BY expressions.
fixes #3338
- Add a test that includes a composed label in a GROUP BY

these files are present.