index.asciidoc 7.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225
  1. [role="xpack"]
  2. [testenv="basic"]
  3. [[sql-lexical-structure]]
  4. === Lexical Structure
  5. This section covers the major lexical structure of SQL, which for the most part, is going to resemble that of ANSI SQL itself hence why low-levels details are not discussed in depth.
  6. {es-sql} currently accepts only one _command_ at a time. A command is a sequence of _tokens_ terminated by the end of input stream.
  7. A token can be a __key word__, an _identifier_ (_quoted_ or _unquoted_), a _literal_ (or constant) or a special character symbol (typically a delimiter). Tokens are typically separated by whitespace (be it space, tab) though in some cases, where there is no ambiguity (typically due to a character symbol) this is not needed - however for readability purposes this should be avoided.
  8. [[sql-syntax-keywords]]
  9. ==== Key Words
  10. Take the following example:
  11. [source, sql]
  12. ----
  13. SELECT * FROM table
  14. ----
  15. This query has four tokens: `SELECT`, `*`, `FROM` and `table`. The first three, namely `SELECT`, `*` and `FROM` are __key words__ meaning words that have a fixed meaning in SQL. The token `table` is an _identifier_ meaning it identifies (by name) an entity inside SQL such as a table (in this case), a column, etc...
  16. As one can see, both key words and identifiers have the _same_ lexical structure and thus one cannot know whether a token is one or the other without knowing the SQL language; the complete list of key words is available in the <<sql-syntax-reserved, reserved appendix>>.
  17. Do note that key words are case-insensitive meaning the previous example can be written as:
  18. [source, sql]
  19. ----
  20. select * fRoM table;
  21. ----
  22. Identifiers however are not - as {es} is case sensitive, {es-sql} uses the received value verbatim.
  23. To help differentiate between the two, through-out the documentation the SQL key words are upper-cased a convention we find increases readability and thus recommend to others.
  24. [[sql-syntax-identifiers]]
  25. ==== Identifiers
  26. Identifiers can be of two types: __quoted__ and __unquoted__:
  27. [source, sql]
  28. ----
  29. SELECT ip_address FROM "hosts-*"
  30. ----
  31. This query has two identifiers, `ip_address` and `hosts-*` (an <<multi-index,index pattern>>). As `ip_address` does not clash with any key words it can be used verbatim, `hosts-*` on the other hand cannot as it clashes with `-` (minus operation) and `*` hence the double quotes.
  32. Another example:
  33. [source, sql]
  34. ----
  35. SELECT "from" FROM "<logstash-{now/d}>"
  36. ----
  37. The first identifier from needs to quoted as otherwise it clashes with the `FROM` key word (which is case insensitive as thus can be written as `from`) while the second identifier using {es} <<date-math-index-names>> would have otherwise confuse the parser.
  38. Hence why in general, *especially* when dealing with user input it is *highly* recommended to use quotes for identifiers. It adds minimal increase to your queries and in return offers clarity and disambiguation.
  39. [[sql-syntax-literals]]
  40. ==== Literals (Constants)
  41. {es-sql} supports two kind of __implicitly-typed__ literals: strings and numbers.
  42. [[sql-syntax-string-literals]]
  43. [float]
  44. ===== String Literals
  45. A string literal is an arbitrary number of characters bounded by single quotes `'`: `'Giant Robot'`.
  46. To include a single quote in the string, escape it using another single quote: `'Captain EO''s Voyage'`.
  47. NOTE: An escaped single quote is *not* a double quote (`"`), but a single quote `'` _repeated_ (`''`).
  48. [sql-syntax-numeric-literals]
  49. [float]
  50. ===== Numeric Literals
  51. Numeric literals are accepted both in decimal and scientific notation with exponent marker (`e` or `E`), starting either with a digit or decimal point `.`:
  52. [source, sql]
  53. ----
  54. 1969 -- integer notation
  55. 3.14 -- decimal notation
  56. .1234 -- decimal notation starting with decimal point
  57. 4E5 -- scientific notation (with exponent marker)
  58. 1.2e-3 -- scientific notation with decimal point
  59. ----
  60. Numeric literals that contain a decimal point are always interpreted as being of type `double`. Those without are considered `integer` if they fit otherwise their type is `long` (or `BIGINT` in ANSI SQL types).
  61. [[sql-syntax-generic-literals]]
  62. [float]
  63. ===== Generic Literals
  64. When dealing with arbitrary type literal, one creates the object by casting, typically, the string representation to the desired type. This can be achieved through the dedicated <<sql-operators-cast, cast operator>> and <<sql-functions-type-conversion, functions>>:
  65. [source, sql]
  66. ----
  67. 123::LONG -- cast 123 to a LONG
  68. CAST('1969-05-13T12:34:56' AS TIMESTAMP) -- cast the given string to datetime
  69. CONVERT('10.0.0.1', IP) -- cast '10.0.0.1' to an IP
  70. ----
  71. Do note that {es-sql} provides functions that out of the box return popular literals (like `E()`) or provide dedicated parsing for certain strings.
  72. [[sql-syntax-single-vs-double-quotes]]
  73. ==== Single vs Double Quotes
  74. It is worth pointing out that in SQL, single quotes `'` and double quotes `"` have different meaning and *cannot* be used interchangeably.
  75. Single quotes are used to declare a <<sql-syntax-string-literals, string literal>> while double quotes for <<sql-syntax-identifiers, identifiers>>.
  76. To wit:
  77. [source, sql]
  78. ----
  79. SELECT "first_name" <1>
  80. FROM "musicians" <1>
  81. WHERE "last_name" <1>
  82. = 'Carroll' <2>
  83. ----
  84. <1> Double quotes `"` used for column and table identifiers
  85. <2> Single quotes `'` used for a string literal
  86. [NOTE]
  87. To escape single or double quotes, one needs to use that specific quote one more time. For example, the literal `John's` can be escaped like
  88. `SELECT 'John''s' AS name`. The same goes for double quotes escaping - `SELECT 123 AS "test""number"` will display as a result a column with the name `test"number`.
  89. [[sql-syntax-special-chars]]
  90. ==== Special characters
  91. A few characters that are not alphanumeric have a dedicated meaning different from that of an operator. For completeness these are specified below:
  92. [cols="^m,^15"]
  93. |===
  94. s|Char
  95. s|Description
  96. |* | The asterisk (or wildcard) is used in some contexts to denote all fields for a table. Can be also used as an argument to some aggregate functions.
  97. |, | Commas are used to enumerate the elements of a list.
  98. |. | Used in numeric constants or to separate identifiers qualifiers (catalog, table, column names, etc...).
  99. |()| Parentheses are used for specific SQL commands, function declarations or to enforce precedence.
  100. |===
  101. [[sql-syntax-operators]]
  102. ==== Operators
  103. Most operators in {es-sql} have the same precedence and are left-associative. As this is done at parsing time, parenthesis need to be used to enforce a different precedence.
  104. The following table indicates the supported operators and their precedence (highest to lowest);
  105. [cols="^2m,^,^3"]
  106. |===
  107. s|Operator/Element
  108. s|Associativity
  109. s|Description
  110. |.
  111. |left
  112. |qualifier separator
  113. |::
  114. |left
  115. |PostgreSQL-style type cast
  116. |+ -
  117. |right
  118. |unary plus and minus (numeric literal sign)
  119. |* / %
  120. |left
  121. |multiplication, division, modulo
  122. |+ -
  123. |left
  124. |addition, subtraction
  125. |BETWEEN IN LIKE
  126. |
  127. |range containment, string matching
  128. |+++< > <= >= = <=> <> !=+++
  129. |
  130. |comparison
  131. |NOT
  132. |right
  133. |logical negation
  134. |AND
  135. |left
  136. |logical conjunction
  137. |OR
  138. |left
  139. |logical disjunction
  140. |===
  141. [[sql-syntax-comments]]
  142. ==== Comments
  143. {es-sql} allows comments which are sequence of characters ignored by the parsers.
  144. Two styles are supported:
  145. Single Line:: Comments start with a double dash `--` and continue until the end of the line.
  146. Multi line:: Comments that start with `/*` and end with `*/` (also known as C-style).
  147. [source, sql]
  148. ----
  149. -- single line comment
  150. /* multi
  151. line
  152. comment
  153. that supports /* nested comments */
  154. */
  155. ----