From 5f27a95346a33c8be1eba1f1c94f30e87911adea Mon Sep 17 00:00:00 2001 From: Emily Li Date: Tue, 21 Jul 2020 16:13:48 -0700 Subject: [PATCH] Fix grammar mistake in SQL data type docs. (#60028) Remove an extra 'when'. --- docs/reference/sql/language/data-types.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/reference/sql/language/data-types.asciidoc b/docs/reference/sql/language/data-types.asciidoc index 6dc67161cdd..d6318911d5f 100644 --- a/docs/reference/sql/language/data-types.asciidoc +++ b/docs/reference/sql/language/data-types.asciidoc @@ -97,7 +97,7 @@ A core concept in {es} is that of an `analyzed` field, that is a full-text value to be effectively indexed. These fields are of type <> and are not used for sorting or aggregations as their actual value depends on the <> used hence why {es} also offers the <> type for storing the _exact_ value. -In most case, and the default actually, is to use both types when for strings which {es} supports through <>, that is the ability to index the same string in multiple ways; for example index it both as `text` for search but also as `keyword` for sorting and aggregations. +In most case, and the default actually, is to use both types for strings which {es} supports through <>, that is the ability to index the same string in multiple ways; for example index it both as `text` for search but also as `keyword` for sorting and aggregations. As SQL requires exact values, when encountering a `text` field {es-sql} will search for an exact multi-field that it can use for comparisons, sorting and aggregations. To do that, it will search for the first `keyword` that it can find that is _not_ normalized and use that as the original field _exact_ value.