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]

has_table issues are OK.  On OSX forget it.
- still some issues with PY3k + pyodbc + decimal values it doesn't expect, not sure

reflected by the SQLite dialect; courtesy Russell Stuart.
[ticket:2764]

This controls the value of the ``retaining`` flag sent to the
``commit()`` and ``rollback()`` methods of the DBAPI connection.
Defaults to False.  Also in 0.8.2, where it defaults to True.
[ticket:2763]

Postgresql dialect to no longer inject a hardcoded ``::timestamp``
or similar cast into the given expression, as this interfered
with types such as timezone-aware datetimes, but also
does not appear to be at all necessary with modern versions
of psycopg2.  Also in 0.8.2.
[ticket:2740]

INT64 has been fixed so that LONG is treated as INTEGER,
INT64 treated as BIGINT, unless the type has a "precision"
in which case it's treated as NUMERIC.  Patch courtesy
Russell Stuart.
[ticket:2757]

backslashed quotes would not be escaped correctly when
using the "non native" (i.e. non-psycopg2) means
of translating HSTORE data.  Patch courtesy Ryan Kelly.
[ticket:2766]

Conflicts:
	doc/build/changelog/changelog_08.rst
	doc/build/changelog/changelog_09.rst

- add support for correlations to propagate all the way in; because
correlations require context now, need to make sure a select enclosure
of any level takes effect any number of levels deep.
- fix what we said correlate_except() was supposed to do when we first
released #2668 - "the FROM clause is left intact if the correlated SELECT
is not used in the context of an enclosing SELECT..." - it was not
considering the "existing_froms" collection at all, and prohibited
additional FROMs from being placed in an any() or has().
- add test for multilevel any()
- lots of docs, including glossary entries as we really need to define
"WHERE clause", "columns clause" etc. so that we can explain correlation better
- based on the insight that a SELECT can correlate anything that ultimately
came from an enclosing SELECT that links to this one via WHERE/columns/HAVING/ORDER BY,
have the compiler keep track of the FROM lists that correspond in this way,
link it to the asfrom flag, so that we send to _get_display_froms() the exact
list of candidate FROMs to correlate.  no longer need any asfrom logic in the
Select() itself
- preserve 0.8.1's behavior for correlation when no correlate options are given, not
to mention 0.7 and prior's behavior of not propagating implicit correlation more than one level..
this is to reduce surprises/hard-to-debug situations when a user isn't trying
to correlate anything.