Context
In ESQL we have the ImplicitCasting Analyzer rule, that takes string literals and fields and casts them to some types, like dates, so you can do FN("2020-10-10") instead of FN("2020-10-10"::date).
The TRange function, however, manually handles the string conversion. Leading to some minor code duplication, and the keyword type accepted as a parameter in documetnation, which deviates from the rest of ESQL.
What
To avoid having special cases like this, it would be convenient to remove that parameter type, and let the planner take care of the automatic conversion.
Breaking change
The (only?) side effect of this is that it will accept not just string literals and fields, but also results of other functions, like: TRANGE("2020-10-10", CONCAT("2020-10", "-10")). This isn't currently allowed as an implicit conversion, and existing queries with it would fail, turning this into a breaking change.
This change was attempted in this PR, but reverted after finding that it is a breaking change:
https://github.com/elastic/elasticsearch/pull/139911/changes/471b21cc01a1cbb5f7cf6cd50bc83c317b08ca8a..90a08920fa4701fe7642485cccc533587a9b2f8d#diff-2e779eeed533ffd0ffa9931179dad92045d2ba9deaed1c99893bd497954a44f5
Context
In ESQL we have the
ImplicitCastingAnalyzer rule, that takes string literals and fields and casts them to some types, like dates, so you can doFN("2020-10-10")instead ofFN("2020-10-10"::date).The TRange function, however, manually handles the string conversion. Leading to some minor code duplication, and the keyword type accepted as a parameter in documetnation, which deviates from the rest of ESQL.
What
To avoid having special cases like this, it would be convenient to remove that parameter type, and let the planner take care of the automatic conversion.
Breaking change
The (only?) side effect of this is that it will accept not just string literals and fields, but also results of other functions, like:
TRANGE("2020-10-10", CONCAT("2020-10", "-10")). This isn't currently allowed as an implicit conversion, and existing queries with it would fail, turning this into a breaking change.This change was attempted in this PR, but reverted after finding that it is a breaking change:
https://github.com/elastic/elasticsearch/pull/139911/changes/471b21cc01a1cbb5f7cf6cd50bc83c317b08ca8a..90a08920fa4701fe7642485cccc533587a9b2f8d#diff-2e779eeed533ffd0ffa9931179dad92045d2ba9deaed1c99893bd497954a44f5