refactor(types): spilt timestamp to timestamp and timestampnano #20192
Conversation
|
This pull request has been modified. If you want me to regenerate unit test for any of the files related, please find the file in "Files Changed" tab and add a comment |
timestamp -> 6 us |
I remembered timestamp should already be nano precision. Does it mean this is a breaking change? |
It was also a breaking change regarding the |
Yes. There should be no compatibility issues with this pr, but it will make some user behavior changes |
I am ok with this PR to keep the timestamp with us precision and introduce a new timestampnano type to introduce nano precision timestamp. It can make the code clearer and it doesn't make too much sense to let |
|
I agree. I meant this breaking change is acceptable and can actually "fix"/revert a previous breaking change. |
There was a problem hiding this comment.
Considering other system nano timestamp type naming conventions, I think it's better to use timestamp_ns instead of timestampnano
https://arc.net/l/quote/xaiqjmve
https://duckdb.org/docs/sql/data_types/timestamp.html
save fix ci
xxhZs
force-pushed
the
xxh/nanotimestamp-spilt
branch
from
5492b34 to
776bb4a
Compare
xxhZs
force-pushed
the
xxh/nanotimestamp-spilt
branch
from
61df181 to
3258b9e
Compare
There was a problem hiding this comment.
Summary:
- Stick to
timestamp_ns. Avoid usingtimestampns,timestampnano,timestamp_nanosimultaneously. - We may support operators on
timestamp_nsin future PRs. A lot of them are missing in this PR, or incorrect, or requirestimestamptz_ns/time_ns/interval_nsbefore they can be properly implemented. The minimal ones are: being able to write and read (thus from and into string), and cast from/into timestamp, and generic operators that applies to most datatypes (e.g.is null/case-when/coalesce/count/=/is distinct from... See top 2 sections in Tracking: Basic Built-in Functions #112). - For source and sink, either test each case (can be time consuming) or leave them unimplemented.
| if subsec_nanosecond % 1_000 != 0 { | ||
| return Err(ErrorKind::ParseTimestamp.into()); | ||
| } |
There was a problem hiding this comment.
PostgreSQL tolerates such lossy parsing, and rounds to even:
test=# select '2020-01-01 12:34:56.123456500'::timestamp;
timestamp
----------------------------
2020-01-01 12:34:56.123456
(1 row)
test=# select '2020-01-01 12:34:56.123457500'::timestamp;
timestamp
----------------------------
2020-01-01 12:34:56.123458
(1 row)
There was a problem hiding this comment.
Yes, what's being considered here is restoring rw's very first setting, not sure we want to correct it to pg consistency
| @@ -58,6 +58,7 @@ v_bool boolean, | |||
| v_date date, | |||
| v_timestamp timestamptz, | |||
| v_ts_ntz timestamp, | |||
| v_timestamp_ns timestamp_ns, | |||
xxhZs
force-pushed
the
xxh/nanotimestamp-spilt
branch
from
e0b60d6 to
da71941
Compare
I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
in #19827, we support timestamp with nano, but we can't support interval with nano in a similar way. So we have to introduce the new type, and correspondingly, we should implement the new type timestamp_nano, so we distinguish between timestamp_nano and timestamp in this pr
Checklist
Documentation
Release note