Thank you for pointing out the discussion in the earlier article. I agree, for full outer joins, the ANSI syntax is much more clear than the equivalent SQL statement using Oracle’s classical outer joins.

I attempted to make a couple of points in this article… identifying an apparent ANSI bug as actually not an ANSI bug, but instead a programming bug is just one of those points (does the “RIGHT OUTER” apply to the.order of the columns in the “ON” clause or the order of the row sources in the “JOIN” clause?). I am sure that this is an easy mistake to make, especially when trying to manually translate Oracle’s classical outer joins to work on another database platform, such as SQL Server.

thank you for the interesting analysis. I thought about adding some comments, but then I saw that all I could say about ANSI join syntax (and readability and bugs) was already included in the first article (from 2010) of your series (and in the comments of Tim Hall and William Robertson)…

Regards

Martin

P.S. for FULL OUTER JOINs I prefer the ANSI version, but in most cases I am quite indifferent …

Thanks for the comment. I thought that someone might raise a concern with me using using Oracle Database, SQL*Plus, and autotrace to investigate a SQL Server join issue, that in this particular case is not an actual issue.

I did find it slightly interesting that Oracle Database 11.2.0.2′s optimizer did not transform the outer join into an equijoin due to the declared foreign key. There is probably a good reason for the missing opportunity for an additional optimization, but for right now I am OK with just considering it interesting.