Лексическая структура

Рассмотрим следующий пример:

SELECT * FROM table

Этот запрос содержит четыре токена: SELECT, *, FROM и table. Первые три, а именно SELECT, * и FROM, являются ключевыми словами, то есть словами, имеющими фиксированное значение в SQL. Токен table является идентификатором, то есть он идентифицирует (по имени) сущность внутри SQL, такую как таблица (в данном случае), столбец и т. д.

Как можно видеть, ключевые слова и идентификаторы имеют одинаковую лексическую структуру, и поэтому нельзя определить, является ли токен тем или другим, не зная языка SQL; полный список ключевых слов доступен в приложении с зарезервированными ключевыми словами. Обратите внимание, что ключевые слова нечувствительны к регистру, что означает, что предыдущий пример можно записать как:

select * fRoM table;

Однако идентификаторы нечувствительны к регистру — так как Elasticsearch чувствителен к регистру, Elasticsearch SQL использует полученное значение дословно.

Для лучшего различения между ними в документации ключевые слова SQL пишутся с заглавных букв, что, по нашему мнению, повышает читаемость, и мы рекомендуем это другим.

Идентификаторы могут быть двух типов: в кавычках и без кавычек:

SELECT ip_address FROM "hosts-*"

В этом запросе есть два идентификатора: ip_address и hosts-* (шаблон индекса). Поскольку ip_address не конфликтует ни с одним ключевым словом, его можно использовать дословно, а hosts-* — нет, так как он конфликтует с - (операция вычитания) и *, поэтому используются двойные кавычки.

Еще один пример:

SELECT "from" FROM "<logstash-{now/d}>"

Первый идентификатор в запросе необходимо заключить в кавычки, так как в противном случае он будет конфликтовать с ключевым словом FROM (которое нечувствительно к регистру и может быть записано как from), а второй идентификатор с использованием поддержки Elasticsearch поддержки даты и времени в именах индексов и псевдонимов индексов в противном случае создал бы путаницу для парсера.

Поэтому, в общем, особенно при работе с пользовательским вводом, крайне рекомендуется использовать кавычки для идентификаторов. Это минимально увеличивает ваши запросы, но в ответ обеспечивает ясность и устранение неоднозначности.

Elasticsearch SQL поддерживает два типа неявных литералов: строки и числа.

Строковый литерал — это произвольное количество символов, ограниченных одиночными кавычками ': 'Giant Robot'. Чтобы включить одиночную кавычку в строку, экранируйте её ещё одной одиночной кавычкой: 'Captain EO''s Voyage'.

Числовые литералы принимаются как в десятичной, так и в научной записи с экспоненциальной частью (e или E), начиная с цифры или десятичной точки .:

1969    -- integer notation
3.14    -- decimal notation
.1234   -- decimal notation starting with decimal point
4E5     -- scientific notation (with exponent marker)
1.2e-3  -- scientific notation with decimal point

Числовые литералы, содержащие десятичную точку, всегда интерпретируются как типа double. Те, что без, считаются integer, если они подходят, в противном случае их тип — long (или BIGINT в типах ANSI SQL).

При работе с литералами произвольного типа объект создаётся путём приведения, как правило, строкового представления к нужному типу. Это можно сделать с помощью специального оператора приведения и функций:

123::LONG                                   -- cast 123 to a LONG
CAST('1969-05-13T12:34:56' AS TIMESTAMP)    -- cast the given string to datetime
CONVERT('10.0.0.1', IP)                     -- cast '10.0.0.1' to an IP

Обратите внимание, что Elasticsearch SQL предоставляет функции, которые из коробки возвращают популярные литералы (такие как E()) или предоставляют специальную обработку для определённых строк.

Стоит отметить, что в SQL одинарные кавычки ' и двойные кавычки " имеют разное значение и не могут использоваться взаимозаменяемо. Одинарные кавычки используются для объявления строкового литерала, а двойные кавычки — для идентификаторов.

Например:

SELECT "first_name" 
  FROM "musicians"  
 WHERE "last_name"  
     = 'Carroll'    

Несколько символов, которые не являются буквенно-цифровыми, имеют специальное значение, отличное от значения оператора. Для полноты эти символы указаны ниже:

Большинство операторов в Elasticsearch SQL имеют одинаковый приоритет и являются левоассоциативными. Поскольку это делается во время парсинга, для принудительного изменения приоритета необходимо использовать скобки.

В следующей таблице указаны поддерживаемые операторы и их приоритет (от самого высокого к самому низкому);

Elasticsearch SQL позволяет использовать комментарии, которые представляют собой последовательность символов, игнорируемых анализаторами.

Поддерживаются два стиля:

-- single line comment
/* multi
   line
   comment
   that supports /* nested comments */
   */