I've noticed that incomplete null statements such as IS N are corrected in our syntax tree. This sends the autocomplete down a "completed operator expression" route as opposed to an unknown operator or "to right of column" route. So, ... | EVAL foo IS N/ is interpreted as ... | EVAL foo IS NULL / unless the checks are purely text based (for example).
We should consider whether this is the desired AST behavior (probably not...).
(By the way, ... | EVAL foo IS N/ accidentally correctly suggests IS NULL because the logic for <operator-expression> <suggest> suggests operators that accept the return type of the existing operator expression as their left-hand argument. Since foo IS NULL is of type boolean and IS NULL accepts boolean values, it gets included in the suggestion list which Monaco then filters by the actual prefix (IS N).)
I've noticed that incomplete null statements such as
IS N
are corrected in our syntax tree. This sends the autocomplete down a "completed operator expression" route as opposed to an unknown operator or "to right of column" route. So,... | EVAL foo IS N/
is interpreted as... | EVAL foo IS NULL /
unless the checks are purely text based (for example).We should consider whether this is the desired AST behavior (probably not...).
The optimistic code is here: https://github.com/elastic/kibana/blob/750452e/packages/kbn-esql-ast/src/parser/walkers.ts#L497-L509
(By the way,
... | EVAL foo IS N/
accidentally correctly suggestsIS NULL
because the logic for<operator-expression> <suggest>
suggests operators that accept the return type of the existing operator expression as their left-hand argument. Sincefoo IS NULL
is of type boolean andIS NULL
accepts boolean values, it gets included in the suggestion list which Monaco then filters by the actual prefix (IS N
).)