Why can every RIGHT OUTER JOIN be rewritten as a LEFT OUTER JOIN?

## The two operators are mirror images An outer join preserves one side. `LEFT OUTER JOIN` preserves the table written before the keyword; `RIGHT OUTER JOIN` preserves the table written after it. Nothing else distinguishes them — the `ON` predicate, the NULL-extension rule and the treatment of multiple matches are identical. So for two tables, these are equivalent: ```sql FROM orders o RIGHT OUTER JOIN customers c ON o.customer_id = c.id FROM customers c LEFT OUTER JOIN orders o ON o.customer_id = c.id ``` Both preserve `customers`: every customer appears, and customers with no order come back with the `orders` columns NULL-extended. The rewrite recipe is mechanical — swap the two table references, flip the keyword, leave the `ON` predicate exactly as it was. The predicate needs no change because `=` and the other comparison operators do not care which side of the join a column came from. ## What actually changes One thing does differ: the order in which the tables appear in the `FROM` clause. That affects the column order of `SELECT *`, and therefore anything positional built on top of it — an `INSERT … SELECT *`, a client reading columns by index, or `ORDER BY 3`. It is a good argument for naming columns explicitly rather than a reason to avoid the rewrite. ## Why teams write only LEFT A multi-table `FROM` clause reads as a pipeline: start with the first table, join the second onto it, join the third onto that result, and so on. Each line adds columns to a growing intermediate result. With `LEFT JOIN` throughout, the preserved side is always "everything accumulated so far", which matches how a reader is already thinking. A single `RIGHT JOIN` three lines down reverses that: the preserved side becomes the newly introduced table, and every earlier row is now the discardable one. Readers miss it, reviewers miss it, and the query silently loses rows it appeared to guarantee. The convention that follows is: choose the driving table — the one whose rows must all appear — write it first, and use `LEFT JOIN` for everything after it. ## The rewrite is not always local With exactly two tables, flipping is a two-token edit. With three or more it may not be, because the join chain is evaluated left to right and the table you want preserved has to end up in the right structural position. Consider: ```sql FROM a JOIN b ON b.a_id = a.id RIGHT JOIN c ON c.b_id = b.id ``` Here `c` is preserved against the result of `a JOIN b`. To express that with `LEFT`, `c` must come first and the `a`–`b` inner join must stay a unit: ```sql FROM c LEFT JOIN ( SELECT b.id AS b_id, b.a_id, a.name FROM a JOIN b ON b.a_id = a.id ) t ON t.b_id = c.b_id ``` Standard SQL also allows a parenthesised join expression directly in the `FROM` clause for the same purpose. Either way, the point is that reordering a chain is a real restructuring, not a keyword swap, because outer joins do not commute or associate freely the way inner joins do. ## When you might still meet RIGHT Generated SQL, tools that append joins to an existing query, and hand-edits made under pressure all produce `RIGHT JOIN`. It is legal and correct; the objection is stylistic, not semantic. If you inherit one, the useful first step in review is to convert it, because doing so forces you to state which table you actually intend to preserve — and that is exactly the question a mixed-direction chain makes hard to answer. ## The interview answer Name the preserved side for each keyword, give the two-table swap recipe, say that only column order changes, then add the nuance that separates a rote answer from an understood one: with more than two tables the swap may require reordering the whole chain or wrapping part of it, because outer joins are order-sensitive.