Feedback-ID: ic6394509:Fastmail
MIME-Version: 1.0
Date: Mon, 01 Jun 2026 22:06:44 +0200
From: "Joel Jacobson" <joel@compiler.org>
To: "Laurenz Albe" <laurenz.albe@cybertec.at>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: "Arne Roland" <arne.roland@malkut.net>,
 "Anders Granlund" <anders.granlund.0@gmail.com>,
 "Andreas Karlsson" <andreas@proxel.se>, "Vik Fearing" <vik@chouppes.com>
Message-Id: <9ac96604-8112-4750-b0ca-a6ab41d51d31@app.fastmail.com>
In-Reply-To: <4a34b3e4-fa4c-446d-beb6-45ccac536086@app.fastmail.com>
References: <00c30670-64e1-4c30-a349-784426d333df@app.fastmail.com>
 <264e69aed5a2fdd93ad555dff96daeabc5c35724.camel@cybertec.at>
 <2ac20bea-4130-4cf3-8e13-ea7c6d062296@app.fastmail.com>
 <348b4bd1d4215d475952b7f5527a092a1491a2c1.camel@cybertec.at>
 <f7f02669-652d-4bbb-bc29-cccdb63c2233@app.fastmail.com>
 <4a34b3e4-fa4c-446d-beb6-45ccac536086@app.fastmail.com>
Subject: Re: Key joins
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/9ac96604-8112-4750-b0ca-a6ab41d51d31%40app.fastmail.com>
Precedence: bulk

On Sun, May 31, 2026, at 16:40, Joel Jacobson wrote:
> On Sun, May 31, 2026, at 10:05, Joel Jacobson wrote:
>> On Fri, May 29, 2026, at 18:20, Laurenz Albe wrote:
>>> On Fri, 2026-05-29 at 15:21 +0200, Joel Jacobson wrote:
>>>> We actually originally considered TO and FROM as keywords for indic=
ating
>>>> direction, but FROM in a join clause causes confusion with the FROM
>>>> clause itself.=C2=A0 Our user discussions over the last three years=
 indicates
>>>> that arrows are clearer and less ambiguous.
>>>>=20
>>>> It's also worth to mention that SQL/PGQ also uses ASCII arrows to
>>>> indicate direction for its graph pattern syntax.
>>>
>>> I understand the problem with FROM, and I have no objection to the
>>> arrows.
>>
>> Thanks for reviewing.
>>
>> v7 updates 0002 to match the revised Change Proposal wording for
>> GROUPING SETS/ROLLUP/CUBE:
>
> v8 fixes another nondeterministic isolation-test ordering issue seen by
> cfbot on the FreeBSD machine.
>
> 0001 and 0003 are unchanged from v7.

I noted a small error in 7.4.13 in the paper. The examples incorrectly
used "LEFT JOIN" instead of "JOIN", which made the claim "Both queries,
if accepted, would produce the same result rows" to not hold true.

Fixed subsection below:

=3D=3D=3D

7.4.13 Filtered Views and the PK Side

A key join through a filtered view on the PK side is rejected unless the
FK side supplies matching direct key-equality filter evidence; see
Section 7.3.2. This differs from a query that filters the base table
with a WHERE clause after the join:

For the examples below, assume orders has a NOT NULL customer_id that
references customers (id).

-- Accepted: join the full base table, then filter the result.
SELECT *
FROM orders AS o
JOIN customers AS c FOR KEY (id) <- o (customer_id)
WHERE c.active;

CREATE VIEW active_customers AS
    SELECT * FROM customers WHERE active;

-- Rejected: the view is the PK side and lacks row coverage.
SELECT *
FROM orders AS o
JOIN active_customers AS ac FOR KEY (id) <- o (customer_id);
ERROR:  key join from referencing relation o to referenced relation ac c=
annot be proven
ERROR:  key join from referencing relation o to referenced relation ac c=
annot be proven
LINE 3: JOIN active_customers AS ac FOR KEY (id) <- o (customer_id);
                                    ^
DETAIL:  Not every o (customer_id) value can be proven to have a matchin=
g ac row. Referenced relation ac is filtered before this key join. The r=
elevant operation occurs inside view public.active_customers.

Both queries, if accepted, would produce the same result rows, but would
differ from the key join's perspective. In the first query, the join is
against the full customers table: every order is guaranteed to find its
matching customer, and the WHERE clause filters the result after the
join has been evaluated. In the second query, active_customers is the PK
side, and it is missing inactive customers. An order that references an
inactive customer will not find a match.

This asymmetry is inherent in row coverage. A key join guarantees that
the join will behave as a proper foreign key traversal, producing
exactly one match for each FK row. A filtered PK side breaks this
guarantee unless the missing PK values are matched by filters that
remove the corresponding FK rows before the join.

=3D=3D=3D

/Joel