Re: Key joins - Mailing list pgsql-hackers

From Alexander Melnikov
Subject Re: Key joins
Date
Msg-id YIehqjsPBy_2jrzeuqPBDSda6vlYPJSwh_k8d6N_4K4YdcNzd7USMxBT1bzEtjX6a80VWEilWjhBvU9uK_mgS4ZHXwvJwUBWCq58cafZ6Xw=@protonmail.com
Whole thread
In response to Key joins  ("Joel Jacobson" <joel@compiler.org>)
List pgsql-hackers
On Sunday, August 2nd, 2026 at 9:38, Arne Roland <arne.roland@malkut.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
perFK — 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
insteadof 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



pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Incremental View Maintenance, take 2 (design considerations)
Next
From: Andrey Borodin
Date:
Subject: Re: GiST multirange index scans can fail to return rows