Oracle to PostgreSQL: ANSI outer join syntax in PostgreSQL

We find ourselves at the third article in the Oracle migration series. This time, we look at those strange operators that modify the WHERE clause criteria in Oracle (+). Like everything else, PostgreSQL has a solution for that.

RIGHT JOIN

Oracle supports, and many developers use, ANSI outer JOIN syntax using operators to the qualifications clause.

Typically, that looks something like this:

SELECT *
FROM person, places
WHERE person.id = places.person_id(+)

The objective of this syntax is a right outer join. In set theory terms, this is the subset including all places, regardless of person.

The result of a small sample would look like this:

This syntax is unsupported in PostgreSQL.

To achieve the same result, you would use the standard SQL syntax for outer joins.

SELECT *
FROM persons
RIGHT JOIN places
ON persons.id = places.person_id;

SQL also provides a clarifying adverb OUTER. This clarifier is completely optional, as any RIGHT JOIN is by definition an OUTER join.

FULL JOIN

Similarly, using the Oracle syntax for a full join does not work in PostgreSQL.

SELECT *
FROM persons, places
WHERE persons.id(+) = places(+);

The objective of this syntax is a full list of persons and places whether a person is associated with a place or not.

The result would like like this:

Using PostgreSQL syntax, the query would be written thusly:

SELECT *
FROM persons
FULL JOIN places
ON persons.id = places.person_id;

Again, the OUTER keyword is completely optional.

CROSS JOIN

One distinct advantage of the approach to using keywords rather than implicit relationships is that you are not able to accidentally create a cross product.

The syntax:

SELECT *
FROM persons
LEFT JOIN places;

Will result in an error:

ERROR:  syntax error at or near ";"

Indicating that the statement is not complete at the line ending marker “;”.

PostgreSQL will create the cross join product using the ANSI syntax.

SELECT *
FROM persons, places;

Which is more likely a coding error than the intentional result.

To get this functionality intentionally, it is recommended to use the CROSS JOIN statement.

SELECT *
FROM persons
CROSS JOIN places;

Thus making it unambiguous what was meant in the statement.

NATURAL JOIN

PostgreSQL supports the NATURAL JOIN syntax, but a bit under protest.

SELECT *
FROM persons
NATURAL JOIN places;

This produces the following result.

However, this syntax is a problem. For our example, the “id” column in both tables has nothing to do with each other. This join has produced a result, but one with completely irrelevant content.

Additionally, you may have a query that initially presents the correct result, but subsequent DDL statements silently affect.

Consider:

ALTER TABLE person ADD COLUMN places_id bigint;
ALTER TABLE places ADD COLUMN places_id bigint;
ALTER TABLE person ADD COLUMN person_id bigint;

Now what column is the NATURAL JOIN using? The choices are id, places_id, person_id, and all of the above. I’ll leave the answer as an exercise to the reader.

This syntax is a time bomb for your code. Just don’t use it.

Ok, so you’re not convinced. Well, then at least have some sane coding conventions. For the parent table, name the identity column “myparenttable_id”. When referencing it from child relations, use the same name, “myparenttable_id”.  Never name anything “id”, and never make a reference to a column with a different name. Ah, forget it. Just don’t do this.

You may be tempted to disambiguate the previous puzzle by using the USING keyword. That would look like this:

SELECT *
FROM persons
JOIN places
USING (id);

But the USING keyword can only take advantage of exact name matches across tables. Which again, in our example is just dead wrong.

The best practice choice for PostgreSQL is to simply avoid designing tables by coding convention standards.

Summary

These keyword techniques (vs. operators) are also available on Oracle. They are more cross-platform, and less ambiguous. That alone would make them best practices.

Added to that, they expose logical errors when improperly used. For any development in PostgreSQL, we unilaterally recommend using explicit keywords.