Documentation Source Text

  high-level overview of the chosen query strategy.
}

HEADING 1 {The LIKE optimization} like_opt
hd_keywords {LIKE optimization}

PARAGRAPH {
  A WHERE-clause term that uses the [LIKE] or [GLOB] operator
  can sometimes be used with an index to do a range search, 
  almost as if the LIKE or GLOB were an alternative to a [BETWEEN]
  operator.
  There are many conditions on this optimization:
}
PARAGRAPH {
  <ol>


  <li>^The right-hand side of the LIKE or GLOB must be either a string literal
      or a [parameter] bound to a string literal
      that does not begin with a wildcard character.</li>
  <li>^The ESCAPE clause cannot appear on the LIKE operator.</li>
  <li>It must not be possible to make the LIKE or GLOB operator true by
      having a numeric value (instead of a string or blob) on the
      left-hand side. This means that either:
      <ol type="A">
      <li> the left-hand side of the LIKE or GLOB operator is the name
           of an indexed column with [affinity | TEXT affinity], or</li>
      <li> the right-hand side pattern argument does not begin with a
           minus sign ("-") or a digit.</li>
      </ol>
      This constraint arises from the fact that numbers do not sort in
      lexicographical order.  For example: 9&lt;10 but '9'&gt;'10'.</li>
  <li>^The built-in functions used to implement LIKE and GLOB must not
      have been overloaded using the sqlite3_create_function() API.</li>
  <li>^For the GLOB operator, the column must be indexed using the 
      built-in BINARY collating sequence.</li>
  <li>^For the LIKE operator, if [case_sensitive_like] mode is enabled then
      the column must indexed using BINARY collating sequence, or if
      [case_sensitive_like] mode is disabled then the column must indexed