IS :: STRING [NOT NULL] as an index compatible predicate

modules/ROOT/pages/planning-and-tuning/query-tuning/indexes.adoc

@@ -172,7 +172,7 @@ For more information, see xref::planning-and-tuning/query-tuning/indexes.adoc#ex
 == TEXT indexes
 
 In combination with node label and relationship type predicates, `TEXT` indexes only solve predicates operating on strings.
-That means that `TEXT` indexes are only used when it is known that the predicate evaluates to `null` for all non-string values.
+That means that `TEXT` indexes are only used when it is known that the predicate evaluates to `false` or `null` for all non-string values.
 
 Predicates that only operate on strings are always solvable by a `TEXT` index:
 
@@ -187,6 +187,10 @@ However, other predicates are only used when it is known that the property is co
 
 This means that a `TEXT` index is not able to solve e.g. `a.prop = b.prop`, unless a type constraint also exists on the property.
 
+One can add xref:values-and-types/type-predicate.adoc[type predicate expressions] such as `IS {two-colons} STRING [NOT NULL]` to enforce the String type and possibly the property's existence.
+Note that `null IS {two-colons} STRING` and that indexes do not store entities with `null` properties.
+Therefore, to be able to use the index, one has to guarantee that no `null` entries are to be included, such as through `IS NOT NULL`, `IS {two-colons} STRING NOT NULL`, a property comparison or a constraint.
+
 In summary, `TEXT` indexes support the following predicates:
 
 [cols="2", options="header"]
@@ -223,11 +227,19 @@ ENDS WITH
 
 | Substring search.
 a|
-[source, syntax, role="noheader"]
+[source,syntax,role="noheader"]
 ----
 CONTAINS
 ----
 
+|
+xref:values-and-types/type-predicate.adoc[String type predicates with existence check].
+a|
+[source,syntax,role="noheader"]
+----
+IS :: STRING NOT NULL
+----
+
 |===
 
 [NOTE]
@@ -246,8 +258,8 @@ MATCH (n:Label) WHERE n.prop = $param
 Such queries can be modified to provide this information.
 Depending on how values that are not of type string should be treated, there are two options:
 
-* If rows in which the expression is not of type string should be discarded, then adding `WHERE <expression> STARTS WITH ''` is the right option:
-`MATCH (n:Label) WHERE $param STARTS WITH '' AND n.prop = $param`
+* If rows in which the expression is not of type string should be discarded, then adding `WHERE <expression> IS {two-colons} STRING [NOT NULL]` is the right option:
+`MATCH (n:Label) WHERE $param IS {two-colons} STRING AND n.prop = $param` (See the documentation on xref::values-and-types/type-predicate.adoc[Type predicate expressions] for more information on these predicates)
 * If expressions which are not of type string should be converted to string, then wrapping these in `toString(<expression>)` is the right choice:
 `MATCH (n:Label) WHERE n.prop = toString($param)`
 * If it is known that the property is always of type `STRING`, then it's also possible to xref::planning-and-tuning/query-tuning/indexes.adoc#extending-index-compatibility-with-type-constraints[add a type constraint to help the planner].