Thread

Re: Key joins

Matthias van de Meent <boekewurm+postgres@gmail.com> — 2026-05-29T12:04:00Z

On Thu, 28 May 2026 at 20:48, Joel Jacobson <joel@compiler.org> wrote:
>
> Hi hackers,
>
> This patch implements a new SQL language feature, that we intent to
> submit as a Change Proposal to the WG 3 SQL committee for the next
> meeting in Stockholm in June.  We would greatly appreciate any feedback
> from the community.
>
> Web demo
> --------
>
> The attached Discussion paper has also been published at https://keyjoin.org
> with all examples in the paper runnable in the browser using a patched PGLite.

Re: "8.4 Why Column Lists Instead of Constraint Names" [0]

It's mentioned that the use of named foreign key constraints as key
column list definitions is not part of the proposal because they are
not universally applicable. While I do understand that for some cases
(multiple mentions of the same target table, CTEs, subqueries, ...)
there won't be a (uniquely) named constraint to reference, in many
(possibly most) cases the FK constraint name _will_ uniquely identify
the base table pair to join, and I think that using the FK name should
be supported as a major QoL addition in this proposal.

Note that the FOR KEY (cols) -> alias (cols) is still useful for the
reasons why constraint names can't always be used, but it's probably
not something I'd ever try to use unless I really, really needed the
specific guarantees granted by the new processing while I was writing
the query. `FOR KEY (something) -> something (something)` just doesn't
feel natural to me.


Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

[0]: https://keyjoin.org/#sec8.4