4 ms·
Agreed. Maybe something like this instead: SELECT f.title, f.did, d.name, f.date_prod, f.kind FROM films f JOIN distributors d ON FOREIGN f.fil
by jmull 5y ago
Agreed. Maybe something like this instead:
SELECT f.title, f.did, d.name, f.date_prod, f.kind
FROM films f
JOIN distributors d ON FOREIGN f.films_did_fkey
and
SELECT f.title, f.did, d.name, f.date_prod, f.kind
FROM distributors d
JOIN films f ON FOREIGN films_did_fkey
- silon42 5y ago+1 ... needed at least as an option where FK is not declared
- magicalhippo 5y agoI had a similar suggestion the other day[1], except I chose what to me sounded more English-sounding: JOIN films f USING FOREIGN KEY Here the explicit foreign key, films_did_fkey in this case, could be specified after FOREIGN KEY. This would be similar in syntax to when you force an index for a select statement, at least in the DB we use. [1]: https://news.ycombinator.com/item?id=29687565 https://news.ycombinator.com/item?id=29687565
- zeroimpl 5y agoYeah I think something like this is the way to go. The table name needs to be listed in a consistent manner like all other joins, and I don't think the syntax should be different depending on which order the tables are listed in. With the above proposal, it seems the foreign key name could be left out in the common case of there being only one fkey between the two tables too.
- magicalhippo 5y ago> With the above proposal, it seems the foreign key name could be left out in the common case of there being only one fkey between the two tables too. Yes, this was indeed my intention. The common case with only a single matching foreign key constraint would not require being explicit, but one could be if needed in a natural way. JOIN films f USING FOREIGN KEY films_did_fkey