Re: Key joins

On Sunday, August 2nd, 2026 at 9:38, Arne Roland <arne(dot)roland(at)malkut(dot)net> wrote:

> Hi hackers,
>
> the attached patch breaks up the stored element of the patch series. The

While FOR KEY makes its way through review, a userspace data point: I generate a pair of set-returning SQL functions per FK — client(document) / client_document_list(profile) — and navigate relations through them:

SELECT d.doc_number, c.name
FROM document d, client(d) c
;

The planner inlines these, so plans are identical to explicit joins; works back to 11.

On the 2021 objections: multiple-FK ambiguity is resolved at name-generation time (role prefixes: client_document_list / manager_document_list), so a new FK renames the affected functions and dependent queries break loudly at compile time instead of silently changing meaning; likewise dropping an FK drops the function.

Not an argument against FOR KEY — syntax in core would be strictly better.
Generator:
https://github.com/asmgit/pg_relation_sql

/ Aleksandr Melnikov