ES|QL: Named parameters

[dgieselaar]

Description

Currently, ES|QL supports positional parameters, which allows the query author to inject variables into the query. This is useful for dashboards, where there are often global parameters, like a time range filter, or a KQL string. However, there's no way to use positional parameters for this, as the dashboard doesn't know with what intent the queries were written.

Named parameters can solve this:

FROM traces-apm*
	| WHERE @timestamp >= ${earliest} AND @timestamp < ${latest}
	| EVAL date_bucket = DATE_TRUNC(${bucketSize}, @timestamp)
	| STATS AVG(transaction.duration.us) BY ${groupingField}

One issue here is that in some cases the variable might be null. Consider groupingField being optional. If it were empty, it would lead to a syntactically invalid query:

FROM traces-apm*
	| WHERE @timestamp >= NOW()-24 hours AND @timestamp < NOW()
	| EVAL date_bucket = DATE_TRUNC(1 hour, @timestamp)
	| STATS AVG(transaction.duration.us) BY

Possibly we can solve this by allowing some kind of syntax for conditional templating:

FROM traces-apm*
	| WHERE @timestamp >= ${earliest} AND @timestamp < ${latest}
	| EVAL date_bucket = DATE_TRUNC(${bucketSize}, @timestamp)
	| STATS AVG(transaction.duration.us) ${groupingField ? "BY " + groupingField : ""}

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[stratoula]

This is important for kibana. Right now we have the following limitation:

• timepicker works only if the index has @timestamp field
• if there is no @timestamp field then the user gets all the data (both in dashboards and Discover)
• the user might want to use a different time field with the time picker
• the timepicker working only with the @timestamp field creates confusion to the users (Why the timepicker is disabled in Discover? I am using the timepicker in a dashboard but my charts are not filtered etc)

[ChrisHegarty]

Seems related to this (currently draft) PR #104618