Shouldn't FROM come before SELECT in SQL? (2011)

Original Article ↗ Hacker News Discussion ↗

Whether SQL should put `FROM` before `SELECT` touches on deeper questions about how query languages balance human readability, execution semantics, and tooling support. Commenters note that the current English-like `SELECT ... FROM ...` syntax hinders features like autocomplete and obscures the logical execution order, while alternatives such as LINQ, Kusto, PRQL, and DuckDB’s extensions show that `FROM`-first or pipeline-style forms can be more ergonomic. Others argue that SQL’s age, ecosystem lock‑in, and its original goal of being understandable to non-engineers make radical syntax changes unlikely, suggesting that better tooling or companion DSLs are more realistic paths forward.

FROM vs SELECT Ordering

  • Many argue FROM … SELECT … better matches how people think: define data source(s), then filter/group, then project columns.
  • Supporters say this mirrors how queries execute and would make large, complex SQL files easier to manage and mentally model.
  • Others defend SELECT … FROM … because it starts with the “command” (select/insert/update/delete), matching how statements are classified and scanned in files.
  • English-likeness is cited both ways: simple queries read naturally as “select X from Y,” but more complex, multi-action statements arguably read better with “from” first.

Tooling, Autocomplete, and IDE UX

  • A recurring complaint: with SELECT first, IDEs cannot offer column completion until FROM is written.
  • FROM-first syntaxes (LINQ, Kusto/KQL, PRQL, DuckDB’s optional FROM-first mode, NRQL, ABAP OpenSQL) are praised for enabling better intellisense and stepwise, composable querying.
  • Some think smart IDEs could work around current SQL, others say language-level support is still a big ergonomic win.

Execution Order vs Syntax Order

  • Several posts contrast SQL’s lexical order (SELECT → FROM → WHERE → …) with its “logical” processing order (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY).
  • This mismatch is seen as a teaching and mental-model pain point, especially for newcomers who expect earlier clauses to “see” later ones.

Safety and UPDATE Syntax

  • UPDATE … SET … WHERE … alarms many because SET precedes WHERE; people fear accidentally omitting the WHERE.
  • Common mitigations: write the WHERE first, prototype as SELECT before converting to UPDATE, and use explicit transactions (BEGIN/ROLLBACK, tooling that warns on WHERE-less updates).

Design Goals, English-Likeness, and Alternatives

  • SQL is described as old, English-influenced, and designed for non-technical users; its quirks persist due to network effects.
  • Several posts suggest SQL is “good enough” but messy for composition, advocating specialized query languages or compile-to-SQL DSLs (PRQL, SaneQL, HoneySQL, Datalog-like systems, QUEL-style syntax).
  • Some argue DBs should expose SQL for humans and a separate, more structured API for machines.