The InfluxQL SELECT subset InfluxElixir.Client.Local answers, shaped the way InfluxDB 3 answers it (verified against the engine; see docs/design/2026-09-23_local-influxql.md).

InfluxQL is not SQL with other keywords. Every row carries "iox::measurement" and "time"; rows come back in time order; a row with no selected field value is dropped; an unknown column or measurement is an empty result, not an error; aggregates are named after the function (mean, count, ...) and put time at the lower bound the WHERE gives time (the epoch when it gives none), except a lone selector (MAX, MIN, FIRST, LAST), which returns its point's time and tags; LIMIT and OFFSET apply per GROUP BY series.

This module is pure. parse/1 turns the statement into a query map; run/4 shapes rows the caller has already filtered with the statement's WHERE clause (Client.Local runs it through its SQL engine) and put in time order.

WHERE follows InfluxQL, not SQL (where_plan/2): a missing tag is the empty string (host != 'a' keeps points without host, host = '' finds them), =~ /re/ and !~ /re/ are unanchored matches on tags and false on fields, </> on a tag is false, durations (now() - 30m) are intervals, double-quoted identifiers are exact, and NOT is the engine's parse error. Compared with time, a bare integer or a duration is an offset from the epoch in nanoseconds (time >= 2, time > 0s, time > 1s - 999999999ns), != and <> are the engine's planning error, and a float is refused. The engine pulls time comparisons out of the whole WHERE as if they were joined by AND, so one inside an OR is refused by name. SHOW TAG VALUES [FROM m] WITH KEY = | != | =~ | !~ | IN (...) [WHERE ...] lists values as the engine does, over the last 24 hours unless the WHERE bounds time (parse_show_tag_values/1).

A reserved word (reserved?/1) is no bare identifier: the engine's parse errors for it, and for a select list, FROM, WHERE, GROUP BY, ORDER BY, LIMIT or a statement after a ; that stops short, are positioned in the text as sent and read with the statement's own offset. A field is compared with a literal by the types of the two (b = 1 is false for every row, u > -1 wraps the -1, an integer past the signed range compares as unsigned), LIMIT and OFFSET beyond the signed 64-bit range are the planning error and beyond the unsigned a parse error.

Refused by name, rather than answered wrongly: GROUP BY time(...) (the engine fills every empty bucket), fill(), INTO, SLIMIT/SOFFSET, subqueries, GROUP BY *, functions other than MEAN SUM COUNT MIN MAX FIRST LAST, F(*) other than COUNT(*), plain columns beside anything but a single selector, arithmetic in the select list, several measurements in FROM, sub-second durations in now() - ..., LIMIT / OFFSET on SHOW TAG VALUES, an unsigned field compared with a string, a string field or a tag compared with an integer past the signed range, a field compared with a constant the double cannot fold, a bare non-boolean field inside AND / OR, DISTINCT, and a statement after a ; that the double does not read. A keyword inside a quoted string, quoted identifier or regular expression is not one: WHERE k = 'into' is answered.