andygrove commented on PR #5956:
URL:
https://github.com/apache/datafusion-comet/pull/5956#issuecomment-6001393025
Thanks for the quick turnaround. The merge fix looks right, but the new
query in `trunc_timestamp.sql` doesn't test it. `unix_micros` only runs through
the codegen dispatcher, and a dispatched expression takes its whole subtree
with it, so the `date_trunc` inside `coalesce(unix_micros(date_trunc('YEAR',
ts)) > 0, true)` runs in the JVM too. With the previous merge code put back,
the file still passes, and with `query expect_native(date_trunc)` it fails with
`codegen-dispatched=[date_trunc, unix_micros]`. Could the query compare
`date_trunc` directly, for example `date_trunc('YEAR', ts) IS NULL OR
date_trunc('YEAR', ts) > TIMESTAMP'1970-01-02 00:00:00'`, under
`expect_native(date_trunc)`?
On the result itself, I offered NULL as an option, but it's still a wrong
answer. Spark returns `+294247-01-01`, and before this PR Comet failed the
query. Could a value outside chrono's range raise an error again, or be
computed from the day count with integer calendar math the way DataFusion's
`_date_trunc_coarse_without_tz` does, which has no year limit?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
