Relates #138888
Should functions that implicitly refer to @timestamp try to nullify/load if this is unmapped/missing when we use SET unmapped_fields="load" or "nullify"?
That's a big footgun, potentially, as there's 2 layers of implicit behavior. Per default, we seem to fail the query and inform the user if the @timestamp field is missing when using e.g. TBUCKET. The @timestamp field is special enough that this might already be the correct behavior.
At the very least, we want to emit a warning here.
Example:
FROM employees
| STATS c = COUNT(*) BY tbucket(1 hour)
| KEEP emp_no, language_code, does_not_exist
Currently, this fails with
[tbucket(1 hour)] requires the [@timestamp] field, which was either not present in the source index, or has been dropped or renamed.
Relates #138888
Should functions that implicitly refer to
@timestamptry to nullify/load if this is unmapped/missing when we useSET unmapped_fields="load"or"nullify"?That's a big footgun, potentially, as there's 2 layers of implicit behavior. Per default, we seem to fail the query and inform the user if the
@timestampfield is missing when using e.g.TBUCKET. The@timestampfield is special enough that this might already be the correct behavior.At the very least, we want to emit a warning here.
Example:
Currently, this fails with