How about trailing commas in SQL?

Original Article ↗ Hacker News Discussion ↗

Motivations for trailing commas in SQL

  • Main benefit is easier manual editing of hand-written SQL:
    • Add/remove/reorder list items (SELECT columns, table columns) without juggling commas.
    • Cleaner diffs and git blame (only the changed line, not the previous one to add/remove a comma).
    • Easier to comment out individual lines during interactive exploration and debugging.
  • Consistency with many programming languages (JS, Python, etc.) and some SQL dialects (BigQuery, Snowflake, DuckDB, ClickHouse) that already allow trailing commas.
  • Especially desired for SELECT and CREATE TABLE; some argue adding them there would cover “99% of the pain”.

Arguments against / skepticism

  • Some find trailing commas visually suggest a missing element or bug; they prefer the syntax error as a guardrail.
  • Concern about “Robustness principle”–style leniency: allowing more sloppy input might hide mistakes or encourage unsafe string-built SQL (vs prepared statements).
  • Others see the change as trivial vs the cost/complexity of touching a very old, messy standard and a huge ecosystem; consider this bikeshedding.
  • A subset simply dislike the aesthetics or feel keystroke savings are negligible compared to time spent thinking about logic.

Existing workarounds and styles

  • Leading-comma style in SELECT / lists:
    • Makes all but the first item uniform and visually aligns commas, which some say reduces errors.
    • Critics say it just moves the “special” case and looks non-idiomatic.
  • Tricks to simplify WHERE clauses:
    • Start with WHERE true or WHERE 1=1 (or 1=0 OR 1=1 for DELETE) so every condition uniformly begins with AND/OR.
  • Other hacks: dummy “pad” column, appending a constant at the end, or relying on ORMs / join()-style helpers to construct lists.

Grammar, standards, and partial solutions

  • SQL grammar is already convoluted; adding trailing commas everywhere might introduce ambiguities, especially where keywords can also be identifiers.
  • Some propose:
    • Allowing trailing commas only where they’re unambiguously illegal today (e.g., selected lists, column definitions).
    • Treating commas more like optional separators or even “whitespace” (Clojure-style), though this collides with existing aliasing syntax without mandatory AS.
  • Debate over “backwards compatibility”:
    • Engines can add support without breaking old queries.
    • But new queries using trailing commas won’t run on old engines.

Broader perspectives

  • Some see this as just one more quality-of-life improvement among many small papercuts; others say energy should go into better editors, diff/merge tools, or alternative query languages (PRQL, BigQuery pipe syntax, LISP-like or newline-delimited syntaxes).
  • Several commenters conclude it’s ultimately a style/preference issue: if unambiguous, many would like trailing commas allowed; others will still choose alternative formatting conventions.