[ESQL] Remove the need for parameter classification from the API #137018
Description
TL;DR: remove parameter classification from the ES|QL API. This is an internal concern that either hides useful features (because undocumented) or (when known) unnecessarily complexifies the use of parameterized queries.
ESQL accepts query parameters, however they seem limited to values. Using a parameter for an index or field name results in an error.
POST _query
{
"query": "row ?field_name = 1 | eval result = ?field_name + 42 | keep result",
"params": [{"field_name": "some_field"}]
}
Results in this error: Query parameter [?field_name] with value [some_field] declared as a constant, cannot be used as an identifier
Reading the source code, I found out that there's a "parameter classification" that can be one of value, identifier and pattern and defaults to value.
To parameterize an identifier (a index, field or variable), we have to use a special structure that indicates that the parameter is an identifier:
POST _query
{
"query": "row ?field_name = 1 | eval result = ?field_name + 42 | keep result",
"params": [{"field_name": {"identifier": "some-field"}}]
}
This results in a successful response with "values": [[43]].
The problems with parameter classification
- they're not documented. I discovered by accident that ES|QL actually supports parameters for identifiers, which is a very useful feature.
- even if they were documented, we should not ask users to specify a parameter's classification. A parameter is a parameter, period. The only thing that should be reported to the user is when a parameter's value is incorrect.
- this unnecessarily complexifies the API definition, and hence client libraries if we want to support all classes of parameters. Client libraries currently only support the default "value" parameter class.
In other words, parameter classification is a concern internal to ES|QL, that should be handled during query validation. It should not be exposed to users, and must be removed from the API.