> In this example you provided, if Foreign Keys are to be used by their defined name, why would we need to specify which table we're going to join here? I see,

> In this example you provided, if Foreign Keys are to be used by their defined name, why would we need to specify which table we're going to join here? I see, you're right; we don't need to! Thanks for great improvement! I don't think using "USING" is a wise choice though, as that's already a different way of joining. But I agree WITH isn't very nice either. How about "KEY"? I also think we should avoid reusing "." since that will is used to refer to columns, and the FK is not a column. I think we need a separate token, "->", or something else. With your idea of leaving out the redundant referenced table alias, and using "KEY" instead of "WITH", the FROM clause becomes: FROM permission p LEFT JOIN role r KEY p->permission_role_id_fkey LEFT JOIN team_role tr KEY tr->team_role_role_id_fkey LEFT JOIN team t KEY tr->team_role_team_id_fkey LEFT JOIN user_role ur KEY ur->user_role_role_id_fkey LEFT JOIN "user" u KEY ur->user_role_user_id_fkey WHERE p.id = 1; To comment on your other two comments: > 1) Now when I'm writing queries I have to go look up the foreign key names. This isn't something that I'm often innately familiar with (unless there's a reliable naming convention; spoiler: there never seems to be). Contrasted with field names, I could easily construct half a dozen quick queries against any DB I regularly use by knowing which tables or fields are there. Very valid point. For this idea to be convenient, one would also need to make the default name for newly created foreign keys user-definable. Simply using the referenced table name as the name would work fine in PostgreSQL, where constraint names are only required to be unique per table, and not per namespace as the SQL standard dictates (for really no good reason). E.g. "permission_role_id_fkey" would simply be named "role". But then one might ask: What happens if you create two foreign keys referencing the same table? In PostgreSQL, a number starting at 1 is automatically appended to the name, e.g. if creating another FK on "permissions" referencing "rule", it would be named "permission_role_id_fkey1". > 2) The example you provide are actually less clear than explicitly stating the joined fields. If I have to come in and troubleshoot something down the line, I then have to spend additional time after viewing the query going in search of what the heck fields are involved in team_role_role_id_fkey, rather than just seeing that it's role.id and team_role.role_id. I think this complaint is related to the first one you made. If you do have a simple naming convention, you will see what table is referenced. The actual values of the foreign key column(s) is not very interesting, since they are just referring some foreign row's primary/unique column(s). Why would you ever need to "troubleshoot" the actual values? Since having FKs on such column(s), they will always be correct when set, so if something is to be troubleshooted it ought to be some actual data in the referenced table, which you could manually join-in and inspect, also by manually joining using the FKs, to avoid having to key in the values of the FK column(s).