Re: Foreign key joins revisited

From: Sascha Kuhl <yogidabanli(at)gmail(dot)com>
To: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
Cc: Joel Jacobson <joel(at)compiler(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Foreign key joins revisited
Date: 2021-12-26 21:39:45
Message-ID: CAPvVvKAZjEkqNXy-BYV4RJvwkj1tL3F1L7qJDgu-8NU6MPCy5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

When you join by id, the join is unique. You can have combinations of
fields, with multiple fields. Is it a maximum fields question.

Isaac Morland <isaac(dot)morland(at)gmail(dot)com> schrieb am So., 26. Dez. 2021,
22:37:

> On Sun, 26 Dec 2021 at 16:24, Joel Jacobson <joel(at)compiler(dot)org> wrote:
>
>
>> I think if we combine the ON KEY ... TO ... part of my idea, with your
>> idea, we have a complete neat solution.
>>
>> Maybe we can make them a little more similar syntax wise though.
>>
>> Could you accept "ON KEY" instead of "FOREIGN KEY" for your idea?
>> And would a simple dot work instead of ->?
>>
>
> I’m not fixed on the details; writing FOREIGN KEY just felt natural, and I
> copied the -> from the earlier messages, but I didn’t really mean to
> promote those specific syntax elements.
>
> One question to consider: which columns get included in the join and under
> what names? When we join USING there is just one copy of each column in the
> USING, not one from each source table. This is one of the nicest features
> of USING. With this new feature it seems like it might make sense to omit
> the join fields from the added table; tricky bit is they don't necessarily
> have the same name as existing fields as must be the case with USING.
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-12-26 21:51:30 Re: Foreign key joins revisited
Previous Message Joel Jacobson 2021-12-26 21:38:25 Re: Foreign key joins revisited