LIMIT n and OFFSET m, in either order, end a statement. A clause is the
keyword followed by a value, so a column called offset (an operator or
keyword follows it) stays a column. The engine's answers (verified): a name
is its schema error (500), a number with a fraction, a string or a boolean
the type_coercion error naming the clause and the type, a negative number
the optimizer's error, 0 and NULL are fine. Planning comes before
optimizing, and LIMIT before OFFSET; a negative OFFSET is reported by
push_down_limit when a LIMIT is present and by eliminate_limit when it
is not. A $name is checked the same way once
InfluxElixir.Client.Local.SQLBind knows its value.
Summary
Functions
LIMIT and OFFSET with their $names bound, checked as literals are: the
planner's type error, and the optimizer's negative-number error, which is
returned for the executor to raise in its place (the last element, nil
when there is none).
Checks that the LIMIT and OFFSET clauses of the text after the table are
ones the double reads; sql is the statement, for a refusal. What the
engine's planner finds wrong with them is planning_error/1, what its
optimizer finds is deferred/1: both come after the errors of the clauses
before them.
The optimizer's error for a negative LIMIT or OFFSET of the text after the
table, or nil. The optimizer finds it after simplify_expressions has
folded the WHERE, so a time string it cannot read is reported first.
The LIMIT of the text after the table: a count, a $name or nil.
The OFFSET of the text after the table: a count, a $name or nil.
The planner's error for a LIMIT or OFFSET of the text after the table that
is a name or a fraction, or nil.
The source of a regular expression for what starts a LIMIT or OFFSET clause.
Types
@type clause() :: non_neg_integer() | {:param, binary()} | nil
A LIMIT or OFFSET as the parser keeps it: a count, a $name or none.
Functions
@spec bind(clause(), clause(), %{required(binary()) => term()}) :: {:ok, non_neg_integer() | nil, non_neg_integer() | nil, InfluxElixir.Client.Local.SQLError.t() | nil} | {:error, InfluxElixir.Client.Local.SQLError.t()}
LIMIT and OFFSET with their $names bound, checked as literals are: the
planner's type error, and the optimizer's negative-number error, which is
returned for the executor to raise in its place (the last element, nil
when there is none).
@spec check(binary(), binary()) :: :ok | {:error, InfluxElixir.Client.Local.SQLError.t()}
Checks that the LIMIT and OFFSET clauses of the text after the table are
ones the double reads; sql is the statement, for a refusal. What the
engine's planner finds wrong with them is planning_error/1, what its
optimizer finds is deferred/1: both come after the errors of the clauses
before them.
@spec deferred(binary()) :: InfluxElixir.Client.Local.SQLError.t() | nil
The optimizer's error for a negative LIMIT or OFFSET of the text after the
table, or nil. The optimizer finds it after simplify_expressions has
folded the WHERE, so a time string it cannot read is reported first.
The LIMIT of the text after the table: a count, a $name or nil.
The OFFSET of the text after the table: a count, a $name or nil.
@spec planning_error(binary()) :: InfluxElixir.Client.Local.SQLError.t() | nil
The planner's error for a LIMIT or OFFSET of the text after the table that
is a name or a fraction, or nil.
@spec start_source() :: binary()
The source of a regular expression for what starts a LIMIT or OFFSET clause.