What I mean is that relationships are at the core of the database, so they should--IMHO--be easy. Instead, JOINS feel like some advanced feature that I always see novices struggle with.
E.g. using NATURAL JOINs covers about 1/3 of the use cases where students or apprentices are usually fiddling with INNER JOINs or joining relations using WHERE TableA.ID = TableB.ID, and it's syntax is much simpler.
With a well thought out schema, I personally find that NATURAL JOINs covers about 80% of my needs in that respect, and being unable to NATURAL JOIN tables is beginning to indicate well, not a "code smell" but what I would call a "schema smell".
I fully agree. Joining relations in a relational databases should absolutely be simple - and it absolutely can be:
SELECT col_x, col_y
FROM TableA
NATURAL JOIN TableBx JOIN y ON x.id=y.id
How is this advanced?
The fact that there's an endless number of pitfalls[1] is a characteristic of the operation you're trying to achieve, not a deficiency of SQL. In fact if anything I would say that SQL does a great joke at letting you tweak how you want all those edge cases to be handled.
[1] E.g. What happens if some records are missing on one or the other sides of the join? What happens if ids are not unique?
Might seem like a small improvement, but if you write lots of queries it would be a significant time saver.
x JOIN y
Postgres automatically uses same-name columns for the join. So in the example I gave you, actually "ON x.id=y.id" is redundant. I just added it because if I hadn't someone else would've replied "oh but that only works if you name the columns the same name"
Also, in any less than trivial scenario you will have to think how to handle the edge cases. But again, that's a property of the operation, not of the language.