From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Sat, 8 Jun 2013 23:11:06 +0000 (-0400)
Subject: oracle 9 does support this, oracle 8 is a special case.
X-Git-Tag: rel_0_9_0b1~276
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=10a672e6058048f0f3bc02b180ac7369fc53f6b4;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

oracle 9 does support this, oracle 8 is a special case.
---

diff --git a/doc/build/changelog/migration_09.rst b/doc/build/changelog/migration_09.rst
index e651b08d4c..9f4ed488bd 100644
--- a/doc/build/changelog/migration_09.rst
+++ b/doc/build/changelog/migration_09.rst
@@ -66,11 +66,12 @@ This was due to the fact that SQLite, even today, cannot parse a statement of th
     Error: no such column: b.id
     sqlite>
 
-Back in 2005, it's possible, though not confirmed, that maybe older versions of MySQL
-(like in the 4 series) or Oracle (perhaps in the 8 or 9 series) also couldn't handle the above form;
-though today, every database tested except SQLite now supports it.   To make matters worse,
-SQLAlchemy's usual workaround of applying a SELECT often degrades performance on platforms
-like Postgresql and MySQL::
+Back in 2005, it wasn't clear if other databases had trouble with this form,
+but today it seems clear every database tested except SQLite now supports it
+(Oracle 8, a very old database, doesn't support the JOIN keyword at all,
+but SQLAlchemy has always had a simple rewriting scheme in place for Oracle's syntax).
+To make matters worse, SQLAlchemy's usual workaround of applying a
+SELECT often degrades performance on platforms like Postgresql and MySQL::
 
     SELECT a.*, anon_1.* FROM a JOIN (
                     SELECT b.id AS b_id, c.id AS c_id