Re: Key joins

Joel Jacobson <joel@compiler.org>

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>

Date: 2026-05-31T08:05:28Z

Lists: pgsql-hackers

Attachments

v7-0001-Serialize-routine-definition-changes-with-depende.patch.gz (application/x-gzip)
v7-0002-Implement-FOR-KEY-join-support.patch.gz (application/x-gzip)
v7-0003-Add-information_schema.view_constraint_usage.patch.gz (application/x-gzip)

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 indicating
>> direction, but FROM in a join clause causes confusion with the FROM
>> clause itself.  Our user discussions over the last three years indicates
>> that arrows are clearer and less ambiguous.
>> 
>> 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:

* Row-coverage facts can now pass through GROUPING SETS, ROLLUP, and
  CUBE when one expanded grouping set contains all key columns under the
  same key identity.  This is less conservative than v6: subtotal rows
  with NULLs in omitted grouping columns do not invalidate row coverage,
  since row coverage is about containment of all-non-null key values.

* Uniqueness and not-null handling for grouping sets remain conservative.
  GROUPING SETS/ROLLUP/CUBE do not by themselves prove referenced
  uniqueness or not-nullness; a following DISTINCT or simple GROUP BY can
  still provide uniqueness where needed.

* 0001 and 0003 are unchanged from v6.

/Joel