mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 15:47:23 -04:00
This corrects an earlier mistake in the ES|QL language design. Initially we had thought to have pow return the same type as its inputs, but in practice even for integer inputs this quickly grows out of the representable range, and we returned null much of the time. This also created a lot of edge cases around casting to/from doubles (which the underlying java function uses). The version in this PR follows the java spec, by always casting its inputs to doubles, and returning a double. Doing it this way also allows for a rather significant reduction in lines of code. I removed many of the tests covering pow specific edge cases. This seems reasonable to me as I expect java.lang.math.pow to be well behaved and most of those edge cases were around type testing which no longer applies. At the same time, this simplification allows us to leverage the new scalar function testing framework, which means better null coverage, better type coverage, and much easier extensibility. We do consider this a breaking change, but as the feature is still in tech preview and this is a relatively small surface area, we are not too concerned with disruptions. Resolves #99055 Relates to #100558 --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> |
||
---|---|---|
.. | ||
functions | ||
processing-commands | ||
source-commands | ||
esql-commands.asciidoc | ||
esql-enrich-data.asciidoc | ||
esql-examples.asciidoc | ||
esql-functions-operators.asciidoc | ||
esql-functions.asciidoc | ||
esql-get-started.asciidoc | ||
esql-kibana.asciidoc | ||
esql-language.asciidoc | ||
esql-limitations.asciidoc | ||
esql-process-data-with-dissect-grok.asciidoc | ||
esql-query-api.asciidoc | ||
esql-rest.asciidoc | ||
esql-security-solution.asciidoc | ||
esql-syntax.asciidoc | ||
esql-using.asciidoc | ||
index.asciidoc | ||
metadata-fields.asciidoc | ||
multivalued-fields.asciidoc | ||
task-management.asciidoc |