Postgres 的 Lateral Join 讓構建優質的 eDSL 成為可能

背景

這篇文章探討了 PostgreSQL 中較少被提及的「側向連接」（Lateral Join）功能，並展示如何利用其特性構建出具備高度組合性的嵌入式領域特定語言（eDSL）。作者認為傳統 ORM 在處理複雜查詢與類型安全時往往顯得笨重且難以擴展，而透過側向連接，開發者可以在如 Haskell 或 Rust 等強類型語言中，以更接近原生語言邏輯的方式來組合 SQL 查詢，同時保有資料庫底層的執行效率。

社群觀點

針對側向連接在 eDSL 中的應用，社群展開了關於查詢表達力與開發體驗的深入討論。部分參與者分享了實務經驗，指出側向連接在處理 JSONB 資料格式時極具威力，特別是當需要將巢狀的 JSON 文件轉換為關聯式結構時，側向連接是少數能讓開發者在函數呼叫中明確宣告輸出欄位類型的語法結構。這種特性讓資料能在資料庫層級直接進行轉換，避免了將大量原始資料拉回應用程式層進行序列化與反序列化的效能損耗。

在查詢組合的技術選擇上，有留言者提到曾嘗試使用公用表運算式（CTE）來達成類似的模組化效果，但發現 CTE 在語法層面需要區分定義與引用，導致查詢層的封裝邏輯變得複雜，相比之下側向連接的語法一致性在構建查詢工具時更具優勢。然而，對於是否該過度依賴這類抽象層，社群內存在明顯的分歧。支持者認為，當面對具有大量選填條件或複雜關聯的高階參數化查詢時，純 SQL 容易導致代碼重複且難以重構，一個設計良好的 ORM 或 eDSL 能在維持類型安全的同時簡化開發流程。

反對者則傾向於「直接撰寫 SQL」的純粹主義。有觀點認為，許多 ORM 雖然在簡單查詢時很方便，但一旦涉及效能調優或極其複雜的邏輯，開發者最終仍需回歸原生 SQL。這種觀點強調，與其在半成品般的 DSL 中掙扎，不如精通 SQL 語法，並在必要時配合預存程序或參數化腳本。此外，討論中也觸及了 SQL 撰寫風格的爭議，例如關鍵字是否該大寫、縮排習慣以及 Join 條件的擺放位置等，反映出開發者對於 SQL 可讀性的高度重視。整體而言，社群共識傾向於尋找一個平衡點：既能享受 ORM 帶來的開發效率，又能在關鍵時刻無縫切換回原生 SQL 進行精細控制。

延伸閱讀

• Modern SQL 關於 WITH 子句（CTE）的介紹：詳細說明了 SQL 標準中用於組合查詢的另一種機制。
• PostgreSQL 官方文件關於 SELECT 語法的說明：特別是針對側向連接與函數返回記錄集（Recordset）的語法規範。