Merge branch 'ticket_2746'

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

diff --cc doc/build/changelog/changelog_08.rst
index f76d5c95c21907a4e41d36f3a8a2110bcd0d854e,ba2450d55cc638ede4a341279a389299fee6b7af..ef87fea453c8d6165540d8b6d9ab8d3b6049918f
--- 1/doc/build/changelog/changelog_08.rst
--- 2/doc/build/changelog/changelog_08.rst
+++ b/doc/build/changelog/changelog_08.rst
@@@ -7,13 -7,40 +7,47 @@@
      :version: 0.8.2
  
      .. change::
 +        :tags: bug, postgresql
 +        :tickets: 2767
 +
 +        Fixed bug where the order of columns in a multi-column
 +        Postgresql index would be reflected in the wrong order.
 +        Courtesy Roman Podolyaka.
 +
+         :tags: bug, sql
+         :tickets: 2746, 2668
+ 
+         Multiple fixes to the correlation behavior of
+         :class:`.Select` constructs, first introduced in 0.8.0:
+ 
+         * To satisfy the use case where FROM entries should be
+           correlated outwards to a SELECT that encloses another,
+           which then encloses this one, correlation now works
+           across multiple levels when explicit correlation is
+           established via :meth:`.Select.correlate`, provided
+           that the target select is somewhere along the chain
+           contained by a WHERE/ORDER BY/columns clause, not
+           just nested FROM clauses. This makes
+           :meth:`.Select.correlate` act more compatibly to
+           that of 0.7 again while still maintaining the new
+           "smart" correlation.
+ 
+         * When explicit correlation is not used, the usual
+           "implicit" correlation limits its behavior to just
+           the immediate enclosing SELECT, to maximize compatibility
+           with 0.7 applications, and also prevents correlation
+           across nested FROMs in this case, maintaining compatibility
+           with 0.8.0/0.8.1.
+ 
+         * The :meth:`.Select.correlate_except` method was not
+           preventing the given FROM clauses from correlation in
+           all cases, and also would cause FROM clauses to be incorrectly
+           omitted entirely (more like what 0.7 would do),
+           this has been fixed.
+ 
+         * Calling `select.correlate_except(None)` will enter
+           all FROM clauses into correlation as would be expected.
+ 
      .. change::
          :tags: bug, ext
  

diff --cc doc/build/changelog/changelog_09.rst
index 24a8e5084554629c89ed4e6db48fe3ac9dd42265,abf0fde41aeb7ea829c91ae5cadf7d96993443c0..57cf0da31ab6044119f0a73691ada898d5edcdc3
--- 1/doc/build/changelog/changelog_09.rst
--- 2/doc/build/changelog/changelog_09.rst
+++ b/doc/build/changelog/changelog_09.rst
@@@ -7,13 -7,42 +7,49 @@@
      :version: 0.9.0
  
      .. change::
 +        :tags: bug, postgresql
 +        :tickets: 2767
 +
 +        Fixed bug where the order of columns in a multi-column
 +        Postgresql index would be reflected in the wrong order.
 +        Courtesy Roman Podolyaka.  Also in 0.8.2.
 +
+         :tags: bug, sql
+         :tickets: 2746, 2668
+ 
+         Multiple fixes to the correlation behavior of
+         :class:`.Select` constructs, first introduced in 0.8.0:
+ 
+         * To satisfy the use case where FROM entries should be
+           correlated outwards to a SELECT that encloses another,
+           which then encloses this one, correlation now works
+           across multiple levels when explicit correlation is
+           established via :meth:`.Select.correlate`, provided
+           that the target select is somewhere along the chain
+           contained by a WHERE/ORDER BY/columns clause, not
+           just nested FROM clauses. This makes
+           :meth:`.Select.correlate` act more compatibly to
+           that of 0.7 again while still maintaining the new
+           "smart" correlation.
+ 
+         * When explicit correlation is not used, the usual
+           "implicit" correlation limits its behavior to just
+           the immediate enclosing SELECT, to maximize compatibility
+           with 0.7 applications, and also prevents correlation
+           across nested FROMs in this case, maintaining compatibility
+           with 0.8.0/0.8.1.
+ 
+         * The :meth:`.Select.correlate_except` method was not
+           preventing the given FROM clauses from correlation in
+           all cases, and also would cause FROM clauses to be incorrectly
+           omitted entirely (more like what 0.7 would do),
+           this has been fixed.
+ 
+         * Calling `select.correlate_except(None)` will enter
+           all FROM clauses into correlation as would be expected.
+ 
+         Also in 0.8.2.
+ 
      .. change::
          :tags: bug, ext