that ``discriminator_on_association.py`` makes use of single table
inheritance do the work with the "discriminator".  Also
added a true "generic foreign key" example, which works similarly
to other popular frameworks in that it uses an open-ended integer
to point to any other table, foregoing traditional referential
integrity.  While we don't recommend this pattern, information wants
to be free.  Also in 0.8.3.

- Added a convenience class decorator :func:`.as_declarative`, is
a wrapper for :func:`.declarative_base` which allows an existing base
class to be applied using a nifty class-decorated approach.  Also
in 0.8.3.

"propagate" flags could potentially be mis-configured in some
"unmapped base class" configurations.  Also in 0.8.3.
[ticket:2786]

:class:`.Column` object would not be propagated.  Also in 0.8.3, 0.7.11.
[ticket:2784]

when loading mapped entities.   The function overhead of applying
a per-object deferred callable to an instance at load time was
significantly higher than that of just loading the data from the row
(note that ``defer()`` is meant to reduce DB/network overhead, not
necessarily function call count); the function call overhead is now
less than that of loading data from the column in all cases.  There
is also a reduction in the number of "lazy callable" objects created
per load from N (total deferred values in the result) to 1 (total
number of deferred cols).
[ticket:2778]

regexp apparently were not fully implemented correctly; while the
arguments were accepted, in practice they would have no effect;
this has been fixed.  Also in 0.8.3.
[ticket:2781]

form of a some expressions when referring to the ``.c`` collection
on a ``select()`` construct, but the ``str()`` form isn't available
since the element relies on dialect-specific compilation constructs,
notably the ``__getitem__()`` operator as used with a Postgresql
``ARRAY`` element.  The fix also adds a new exception class
:class:`.UnsupportedCompilationError` which is raised in those cases
where a compiler is asked to compile something it doesn't know
how to.  Also in 0.8.3.
[ticket:2780]

is recreated, due to a disconnect error.   This fixes a particular
issue in the Oracle 8 dialect, but in general the dialect.initialize()
phase should only be once per dialect.  Also in 0.8.3. [ticket:2776]