On Thu, 28 May 2026 at 20:48, Joel Jacobson <[email protected]> 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
