Pipe Syntax in SQL

Original Article ↗ Hacker News Discussion ↗

Paper format & accessibility

  • Many complain that research is only published as two-column PDFs, which are hard to read on mobile, less accessible, and harder to deep-link or copy from than HTML.
  • Others defend PDFs for layout quality, printability, and TeX typesetting; some reviewers even render web articles to PDF for editing.
  • Accessibility concerns are raised (e.g., photophobia, need for dark mode and reader modes), where HTML is clearly superior.
  • There’s discussion of offline, self-contained web bundles. Existing options (base64 assets, WARC) are seen as unsatisfying; people want an explicit “offline-only” format browsers enforce.
  • One commenter demonstrates converting the PDF to semantic HTML using an LLM, with surprisingly good results.

Pipe syntax proposal: enthusiasm

  • Many long-time SQL users say complex queries are hard to express and debug; pipe syntax maps better to how they think about stepwise transformations.
  • Pipes align well with how query planners already think (tables flowing through unary operators), so the written order now matches the conceptual execution order.
  • Pipes can reduce the need for multiple CTEs, especially for “top N then aggregate” patterns where ORDER/LIMIT need to precede aggregation.
  • Supporters like starting from FROM for better autocompletion and readability, similar to R’s dplyr, KQL, PRQL, Polars, dataframe APIs, and Unix-style pipelines.

Pipe syntax proposal: skepticism & design concerns

  • Some argue SQL is already very successful and the main issues are tooling or user understanding, not syntax.
  • Critics worry pipes add “imperative-feeling” sugar to a declarative language and may obscure the optimizer’s freedom.
  • Multiple WHERE clauses replacing WHERE/HAVING/QUALIFY are seen by some as reducing explicitness and potentially causing confusion.
  • Others feel complex multi-join, graph-shaped queries are better modeled by CTEs/subqueries; pipes are seen as mainly helpful for linear, single-table flows.
  • Concerns are raised about clutter, loss of clause ordering guarantees (e.g., always finding ORDER BY at the end), and queries becoming “alien” to existing SQL users.

CTEs, optimization, and performance

  • Pipe syntax is framed as ergonomically better than stacking CTEs, but not fundamentally more optimizable; engines with weak CTE optimization likely won’t magically improve.
  • Some note CTEs can be optimization barriers or syntactic expansions that complicate plans; others use temp tables instead.
  • Several emphasize that keeping complex transformations in SQL is crucial for performance and avoiding massive data transfers; using an external language for transformations is usually far slower.

Adoption, standards & tooling

  • The proposal currently comes from a single vendor and is seen as unlikely to hit ISO SQL soon without broad buy-in (Postgres, MySQL/MariaDB, SQL Server, Oracle).
  • Some want transpilers/AST tooling (e.g., sqlglot-style) and cross-dialect support before adopting new syntax.
  • Pipe syntax is implemented as an extension in ZetaSQL and can be mixed with standard SQL; some see this incremental, backwards-compatible path as its main strength.