Hi hackers, Thank you for this interesting proposal. I have two questions that touch on what I see as a fundamental tension in the design.
On SQL's evolution from How to What As Codd put it, "The user of a relational system should not need to know how the system stores and accesses data." Key Join, I would argue, pulls in the opposite direction. SQL has historically evolved away from procedural "how" toward declarative "what" — users describe the result they want, and the optimizer figures out how to get there. Foreign key constraints are a good example: once declared in the schema, the optimizer can already exploit them for join elimination, cardinality estimation, and so on. Key Join asks users to explicitly annotate their queries with FK traversal semantics. Isn't that a step back toward "how"? Tomas Vondra raised a directly relevant point in his review: > I'm interested in this patch because there seems to be a possible > overlap with the starjoin planning (in that maybe we could try > reusing some of the derived information for that). And later: > Plus, I don't want to make that patch dependent on people using > new syntax. If that can give us additional information, that would > be a different thing. His second remark seems to carry an implicit question: if the optimizer can already see the FK constraints, why does the user need to annotate the query at all? Wouldn't automatic starjoin-style optimization be more consistent with SQL's declarative philosophy? This reading is also supported by his point 13, where he explicitly asks whether the planner — rather than parse-analyze — might be the more appropriate place to handle this, and notes that moving it there could substantially reduce the code footprint. On hints vs. syntax Traditionally, when users have needed to pass extra information to the optimizer — information the engine couldn't derive on its own — the community has handled this through hints. Non-standard, yes, but they leave the core syntax untouched and stay firmly in the optimizer's domain. Key Join introduces this information as first-class syntax with compile-time enforcement. What are the concrete advantages and disadvantages of that choice compared to a hint-based approach? Specifically: The main advertised advantage is compile-time correctness enforcement — catching fan-out bugs at parse time rather than silently producing wrong results. Is that benefit sufficient to justify introducing "how" semantics into SQL syntax proper? A hint could achieve the optimizer-side benefits (starjoin planning, cardinality guidance) without touching the grammar. What does the syntax approach give us that a hint cannot? I recognize that compile-time enforcement is genuinely valuable, and that hints cannot be standardized through WG3. But I'd like to understand how the authors weigh those tradeoffs, especially given Tomas's observation that the planner already has access to FK information and could potentially derive much of this automatically. Best regards, Henson
