From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Fri, 24 Apr 2015 22:01:20 +0000 (-0400)
Subject: - reword the notes here
X-Git-Tag: rel_1_0_2~1
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=723e07a3744c42e24e509edcb6bf45940be74594;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

- reword the notes here
---

diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst
index ed9d41ec4f..6ddba8494e 100644
--- a/doc/build/changelog/changelog_10.rst
+++ b/doc/build/changelog/changelog_10.rst
@@ -29,14 +29,18 @@
         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.
+        even though 1.0 includes a rewrite of this logic as part of 
+        :ticket:`2992`.  As far
+        as emitting GROUP BY against a simple label, even Postgresql has
+        cases where it will raise an error even though the label to group 
+        on should be apparent, so it is clear that GROUP BY should never
+        be rendered in this way automatically.
+
+        In 1.0.2, SQL Server, Firebird and others will again emit ORDER BY on 
+        a simple label name when passed a
+        :class:`.Label` construct that is also present in the columns clause.
+        Additionally, no backend will emit GROUP BY against the simple label
+        name only when passed a :class:`.Label` construct.
 
     .. change::
         :tags: bug, orm, declarative