From 723e07a3744c42e24e509edcb6bf45940be74594 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Fri, 24 Apr 2015 18:01:20 -0400 Subject: [PATCH] - reword the notes here --- doc/build/changelog/changelog_10.rst | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) 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 -- 2.47.3