Re: Foreign key joins revisited

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: Foreign key joins revisited
Дата
Msg-id a9a9c45b-7c90-45dc-bdcf-7b3b32a97d41@www.fastmail.com
обсуждение исходный текст
Ответ на Re: Foreign key joins revisited  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Foreign key joins revisited  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Foreign key joins revisited  (Vik Fearing <vik@postgresfriends.org>)
Список pgsql-hackers
On Mon, Dec 27, 2021, at 19:15, Tom Lane wrote:
> NATURAL JOIN is widely regarded as a foot-gun that the SQL committee
> should never have invented.  Why would we want to create another one?
>
> (I suspect that making the constraint name optional would be problematic
> for reasons of syntax ambiguity, anyway.)

I agree. I remember this blog post from 2013 discussing the problems
with both NATURAL but also the problems with USING:

Since my last email in this thread, I've learned KEY is unfortunately not a reserved keyword.
This probably means the proposed "JOIN KEY" would be problematic, since a relation could be named KEY.

Can with think of some other suitable reserved keyword?

How about JOIN WITH?

join_type JOIN WITH fk_table.fk_name [ [ AS ] alias ]
join_type JOIN fk_table [ [ AS ] alias ] WITH fk_name REF pk_table

FROM permission p
LEFT JOIN WITH p.permission_role_id_fkey r
LEFT JOIN team_role tr WITH team_role_role_id_fkey REF r
LEFT JOIN WITH tr.team_role_team_id_fkey t
LEFT JOIN user_role ur WITH user_role_role_id_fkey REF r
LEFT JOIN WITH ur.user_role_user_id_fkey u
WHERE p.id = 1;

/Joel

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Matheus Alcantara
Дата:
Сообщение: Re: [PROPOSAL] Make PSQLVAR on \getenv opitional
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Foreign key joins revisited