In this PostgreSQL post explains how to use PostgreSQL JOINS (inner and outer) with syntax, visual illustrations, and examples.
PostgreSQL JOINS are used to retrieve data from multiple tables. A PostgreSQL JOIN is performed whenever two or more tables are joined in a SQL statement.
There are different types of PostgreSQL joins:
So let's discuss PostgreSQL JOIN syntax, look at visual illustrations of PostgreSQL JOINS, and explore JOIN examples.
Chances are, you've already written a statement that uses a PostgreSQL INNER JOIN. It is the most common type of join. PostgreSQL INNER JOINS return all rows from multiple tables where the join condition is met.
The syntax for the INNER JOIN in PostgreSQL is:
In this visual diagram, the PostgreSQL INNER JOIN returns the shaded area:
The PostgreSQL INNER JOIN would return the records where table1 and table2 intersect.
Here is an example of a PostgreSQL INNER JOIN:
This PostgreSQL INNER JOIN example would return all rows from the suppliers and orders tables where there is a matching supplier_id value in both the suppliers and orders tables.
Let's look at some data to explain how the INNER JOINS work:
We have a table called suppliers with two fields (supplier_id and supplier_name). It contains the following data:
supplier_id | supplier_name |
---|---|
10000 | IBM |
10001 | Hewlett Packard |
10002 | Microsoft |
10003 | NVIDIA |
We have another table called orders with three fields (order_id, supplier_id, and order_date). It contains the following data:
order_id | supplier_id | order_date |
---|---|---|
500125 | 10000 | 2013/05/12 |
500126 | 10001 | 2013/05/13 |
500127 | 10004 | 2013/05/14 |
If we run the PostgreSQL SELECT statement (that contains an INNER JOIN) below:
Our result set would look like this:
supplier_id | name | order_date |
---|---|---|
10000 | IBM | 2013/05/12 |
10001 | Hewlett Packard | 2013/05/13 |
The rows for Microsoft and NVIDIA from the supplier table would be omitted, since the supplier_id's 10002 and 10003 do not exist in both tables. The row for 500127 (order_id) from the orders table would be omitted, since the supplier_id 10004 does not exist in the suppliers table.
As a final note, it is worth mentioning that the PostgreSQL INNER JOIN example above could be rewritten using the older implicit syntax as follows (but we still recommend using the INNER JOIN keyword syntax):
Another type of join is called a PostgreSQL LEFT OUTER JOIN. This type of join returns all rows from the LEFT-hand table specified in the ON condition and only those rows from the other table where the joined fields are equal (join condition is met).
The syntax for the PostgreSQL LEFT OUTER JOIN is:
In this visual diagram, the PostgreSQL LEFT OUTER JOIN returns the shaded area:
The PostgreSQL LEFT OUTER JOIN would return the all records from table1 and only those records from table2 that intersect with table1.
Here is an example of a PostgreSQL LEFT OUTER JOIN:
This LEFT OUTER JOIN example would return all rows from the suppliers table and only those rows from the orders table where the joined fields are equal.
If a supplier_id value in the suppliers table does not exist in the orders table, all fields in the orders table will display as null> in the result set.
Let's look at some data to explain how LEFT OUTER JOINS work:
We have a table called suppliers with two fields (supplier_id and supplier_name). It contains the following data:
supplier_id | supplier_name |
---|---|
10000 | IBM |
10001 | Hewlett Packard |
10002 | Microsoft |
10003 | NVIDIA |
We have a second table called orders with three fields (order_id, supplier_id, and order_date). It contains the following data:
order_id | supplier_id | order_date |
---|---|---|
500125 | 10000 | 2013/05/12 |
500126 | 10001 | 2013/05/13 |
If we run the SELECT statement (that contains a LEFT OUTER JOIN) below:
Our result set would look like this:
supplier_id | supplier_name | order_date |
---|---|---|
10000 | IBM | 2013/05/12 |
10001 | Hewlett Packard | 2013/05/13 |
10002 | Microsoft | null> |
10003 | NVIDIA | null> |
The rows for Microsoft and NVIDIA would be included because a LEFT OUTER JOIN was used. However, you will notice that the order_date field for those records contains a null> value.
Another type of join is called a PostgreSQL RIGHT OUTER JOIN. This type of join returns all rows from the RIGHT-hand table specified in the ON condition and only those rows from the other table where the joined fields are equal (join condition is met).
The syntax for the PostgreSQL RIGHT OUTER JOIN is:
In this visual diagram, the PostgreSQL RIGHT OUTER JOIN returns the shaded area:
The PostgreSQL RIGHT OUTER JOIN would return the all records from table2 and only those records from table1 that intersect with table2.
Here is an example of a PostgreSQL RIGHT OUTER JOIN:
This RIGHT OUTER JOIN example would return all rows from the orders table and only those rows from the suppliers table where the joined fields are equal.
If a supplier_id value in the orders table does not exist in the suppliers table, all fields in the suppliers table will display as null> in the result set.
Let's look at some data to explain how RIGHT OUTER JOINS work:
We have a table called suppliers with two fields (supplier_id and supplier_name). It contains the following data:
supplier_id | supplier_name |
---|---|
10000 | Apple |
10001 |
We have a second table called orders with three fields (order_id, supplier_id, and order_date). It contains the following data:
order_id | supplier_id | order_date |
---|---|---|
500125 | 10000 | 2013/08/12 |
500126 | 10001 | 2013/08/13 |
500127 | 10002 | 2013/08/14 |
If we run the SELECT statement (that contains a RIGHT OUTER JOIN) below:
Our result set would look like this:
order_id | order_date | supplier_name |
---|---|---|
500125 | 2013/08/12 | Apple |
500126 | 2013/08/13 | |
500127 | 2013/08/14 | null> |
The row for 500127 (order_id) would be included because a RIGHT OUTER JOIN was used. However, you will notice that the supplier_name field for that record contains a null> value.
Another type of join is called a PostgreSQL FULL OUTER JOIN. This type of join returns all rows from the LEFT-hand table and RIGHT-hand table with nulls in place where the join condition is not met.
The syntax for the PostgreSQL FULL OUTER JOIN is:
In this visual diagram, the PostgreSQL FULL OUTER JOIN returns the shaded area:
The PostgreSQL FULL OUTER JOIN would return the all records from both table1 and table2.
Here is an example of a PostgreSQL FULL OUTER JOIN:
This FULL OUTER JOIN example would return all rows from the suppliers table and all rows from the orders table and whenever the join condition is not met, nulls> would be extended to those fields in the result set.
If a supplier_id value in the suppliers table does not exist in the orders table, all fields in the orders table will display as null> in the result set. If a supplier_id value in the orders table does not exist in the suppliers table, all fields in the suppliers table will display as null> in the result set.
Let's look at some data to explain how FULL OUTER JOINS work:
We have a table called suppliers with two fields (supplier_id and supplier_name). It contains the following data:
supplier_id | supplier_name |
---|---|
10000 | IBM |
10001 | Hewlett Packard |
10002 | Microsoft |
10003 | NVIDIA |
We have a second table called orders with three fields (order_id, supplier_id, and order_date). It contains the following data:
order_id | supplier_id | order_date |
---|---|---|
500125 | 10000 | 2013/08/12 |
500126 | 10001 | 2013/08/13 |
500127 | 10004 | 2013/08/14 |
If we run the SQL statement (that contains a FULL OUTER JOIN) below:
Our result set would look like this:
supplier_id | supplier_name | order_date |
---|---|---|
10000 | IBM | 2013/08/12 |
10001 | Hewlett Packard | 2013/08/13 |
10002 | Microsoft | null> |
10003 | NVIDIA | null> |
null> | null> | 2013/08/14 |
The rows for Microsoft and NVIDIA would be included because a FULL OUTER JOIN was used. However, you will notice that the order_date field for those records contains a null> value.
The row for supplier_id 10004 would be also included because a FULL OUTER JOIN was used. However, you will notice that the supplier_id and supplier_name field for those records contain a null> value.