-
Notifications
You must be signed in to change notification settings - Fork 24.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EQL: Remove case_sensitive option #62255
Comments
Pinging @elastic/es-ql (:Query Languages/EQL) |
I think we still need the toggle for the detection engine, since I would expect both case-sensitive and case-insensitive queries to be widely used. @paulewing or @tsg can chime in more |
Yes, from what I understood from @MikePaquette when this has come up before, we want equalities to be case-insensitive by default as that is most common, but there are also cases where we need case-sensitive equals. I'm not a fan of the global case-sensitive option because it introduces a "mode" that is external to the language and it doesn't let the rule author combine case-sensitive and case-insensitive comparisons in the same query. Perhaps we can discuss this one live in the EQL meeting today. |
I'm also against a global param that toggles case-sensitivity.
So, I strongly prefer the per operator/function definition of the case-sensitivity. |
A belated update to this ticket after discussing it further:
In other words, the intent and scope of this ticket remains the same. |
Closed by #63218 |
Currently in EQL, requests allow a
case_sensitive
option for specifying whether string equality is case sensitive or not, as well the behavior for some functions. Initially this was introduced to determine the existing behavior and because the actual implementation requires scripting which is not ideal performance wise.As Elasticsearch now supports such queries, this setting should be removed and EQL be always insensitive, where applicable.
This means:
operators:
==
and!=
. Currently>=
,<=
,<
and>
are not supportedfunctions:
startsWith
,endsWith
,stringContains
,between
,match
,wildcard
(note some regex might not fully support this, requiring the user to change the regex. This is considering missing functionality and will be added asap once the missing bits land in ES).The text was updated successfully, but these errors were encountered: