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.
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
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;
OUTER keyword is completely optional.
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.
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.
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.
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);
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.
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.