>> >IMHO the ANSI standard (as anything designed by a committee) is not
>> always
>> the
>> >best
>> >way to do things.
Hmmm, quite frequently, yes.
< clip >
>> My understanding from reading Date is that one reason for not adopting
>> the common vendor hacks for outer joins is that outer joins aren't
>> associative and the result of complicated expressions in some cases
>> will depend on the order in which the RDBMS' optimizer chooses to
>> execute them.
Yes, that was what I thought as well. I'm not sure what the ANSI standard
specifies, but if it's the style used below (which is what Access uses),
then it's not overly complicated, but can be a little difficult to read
sometimes.
>> Putting on my compiler-writer hat, I can see where having joins
>> explicitly declared in the "from" clauses rather than derived from
>> an analysis of the "from" and "where" clauses might well simplify
>> the development of a new SQL 92 RDBMS if one were to start from
>> scratch. It's cleaner, IMO. This doesn't apply to Postgres,
>> since the outer joins are being shoe-horned into existing data
>> structures.
Does that make any difference?
>> Of course, I speak as someone without
>> a lot of experience writing Oracle or Informix SQL. If you're used
>> to Oracle, then it's not surprising you find its means of specifying
>> an outer join the most natural and easiest to understand...
Yes, you're probably right. Although, I learnt SQL using Access and SQL
Server, doing the 'A INNER JOIN B ON A.x = B.x' syntax, and I still prefer
Oracle's way of doing it. From the developers point of view, it's pretty
easy to read (mainly because it doesn't clutter your FROM clause). Perhaps
the best would be to implement ANSI outer joins, and then use the rewriter
to allow for the Oracle syntax, or something similar, just to add
readability to the SQL.
MikeA
