feat(expr): AT TIME ZONE to convert between timestamp and timestamptz

[xiangjinwu]

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.

What's changed and what's your intention?

Casting between timestamp and timestamp with time zone requires an implicit session TimeZone, which is not supported yet (#5826).

The AT TIME ZONE operator is another way to bridge these two types, via a TimeZone parameter explicitly specified in the query. This PR implements this expr.

• Parser support from upstream: Add support for AT TIME ZONE apache/datafusion-sqlparser-rs#539
• TimeZone parsing relies on chrono-tz with cast-insensitive feature.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

Types of user-facing changes

• SQL commands, functions, and operators

Release note

• timestamp_value AT TIME ZONE 'zone' -> timestamp_with_time_zone_value
• timestamp_with_time_zone_value AT TIME ZONE 'zone' -> timestamp_value

Refer to a related PR or issue link (optional)

[codecov]

Codecov Report

Merging #5968 (9024ca1) into main (d72ba12) will increase coverage by 0.10%.
The diff coverage is 88.79%.

@@            Coverage Diff             @@
##             main    #5968      +/-   ##
==========================================
+ Coverage   74.57%   74.68%   +0.10%     
==========================================
  Files         924      928       +4     
  Lines      147420   147871     +451     
==========================================
+ Hits       109945   110438     +493     
+ Misses      37475    37433      -42     

Flag	Coverage Δ
rust	74.68% <88.79%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/ctl/src/cmd_impl/hummock/list_kv.rs	0.00% <0.00%> (ø)
src/ctl/src/cmd_impl/hummock/sst_dump.rs	0.00% <0.00%> (ø)
src/expr/src/expr/expr_binary_nonnull.rs	71.69% <0.00%> (-5.98%)	⬇️
src/frontend/src/binder/expr/mod.rs	79.88% <0.00%> (-1.83%)	⬇️
src/frontend/src/handler/query.rs	19.52% <0.00%> (-0.72%)	⬇️
src/frontend/src/optimizer/plan_node/mod.rs	84.03% <ø> (ø)
src/frontend/src/optimizer/plan_node/stream.rs	0.00% <0.00%> (ø)
...rontend/src/scheduler/distributed/query_manager.rs	15.21% <0.00%> (-0.12%)	⬇️
src/meta/src/stream/source_manager.rs	45.65% <0.00%> (+0.44%)	⬆️
src/source/src/lib.rs	90.00% <ø> (ø)
... and 112 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[BugenZhao]

Seems we need to parse the timezone every row, not sure whether it can be heavy. 🤔

Some possible optimizations:

• If the second expr is a Constant, use another optimized implementation like perf(expr): optimize to_char function with constant template #5130.
• Use a thread-local memoization / LRU cache.

[xiangjinwu]

The parsing is a lookup of a static and perfect hash table (crate phf), where hash is done in a case-insensitive manner. So memoization / cache has no advantage here.

It is still true that most cases this is a constant, though.

[BugenZhao]

Cool. Then there should be no problem.

[xiangjinwu]

Updated the function name to lookup_time_zone.

[BugenZhao]

LGTM!