背景

PRQL（全稱為 Pipelined Relational Query Language，發音同 Prequel）是一種旨在改進 SQL 語法缺陷的開源查詢語言。它採用線性管道式的轉換邏輯，讓數據查詢過程更易於閱讀與編寫，並能編譯成標準 SQL 以兼容現有的數據庫生態系統。

社群觀點

Hacker News 社群對於 PRQL 的討論首先聚焦於其命名與發音。部分用戶認為，如果一個產品需要特別標註發音指南，通常代表命名不夠直觀，容易在書寫與口語溝通間造成隔閡。這引發了關於技術名詞發音的廣泛爭論，從 SQL 究竟該唸成字母縮寫還是「Sequel」，到 PNG、GIF 甚至 Linux 的發音歷史都被逐一檢視。有觀點指出，SQL 命名混亂的歷史根源在於 IBM 當年的商標法律糾紛，這導致了長達數十年的發音分歧。

在技術層面上，社群對 PRQL 試圖解決的問題有著兩極化的看法。支持者認為 SQL 的語法順序極不符合直覺，特別是 SELECT 子句位於 FROM 之前，這不僅違反了邏輯上的數據流向，也阻礙了現代編輯器提供精準的自動補全功能。PRQL 的管道式結構被視為一種更優雅的抽象，能有效減少複雜查詢中的重複代碼。然而，反對者則主張 SQL 作為一種宣告式語言，其本質更接近關係演算而非簡單的線性管道。有評論指出，複雜的查詢往往呈現圖狀結構而非單一線路，例如涉及多個複雜子查詢的聯結操作，這類場景下管道式語言可能會顯得力不從心。

此外，不少資深開發者對「SQL 替代品」持保留態度。他們認為 SQL 雖然有其歷史包袱，但其生態系統的穩定性與人才普及率是任何新興語言難以企及的。許多人建議與其學習新語言，不如善用 SQL 的公用表表達式（CTE）來達到類似的管道化效果。不過，也有討論提到如 DuckDB 等現代數據庫已經在 SQL 語法上做出務實的改進，例如允許 FROM 置於 SELECT 之前、支持結尾逗號以及自動群組化，這類在既有標準上的微調，或許比完全重新發明一種語言更具吸引力。

最後，關於項目的生命力也引起了關注。儘管 PRQL 的代碼庫仍有更新，但官方部落格的停滯讓部分用戶擔心其開發進度是否受挫。社群也觀察到 Google 推出的 Pipe Syntax 等競爭方案，認為這類背靠大廠且已在生產環境運行的技術，可能會對 PRQL 這種純社群驅動的項目造成競爭壓力。

延伸閱讀

在討論過程中，參與者提到了幾個與改進查詢體驗相關的技術資源：

• Google SQL Pipe Syntax：Google Cloud 實作的管道式 SQL 語法擴充。
• DuckDB Friendly SQL：介紹 DuckDB 如何透過語法優化提升 SQL 的易用性。
• Substrait：旨在建立數據運算計畫的標準化中間層。
• Kusto Query Language (KQL)：微軟開發的另一種廣受好評的管道式查詢語言。
• Verse：一種結合函數式與邏輯編程的語言構想，被認為是處理複雜關係數據的潛在方向。