-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return int32 for integer type date part #13466
Conversation
Signed-off-by: jayzhan211 <[email protected]>
Signed-off-by: jayzhan211 <[email protected]>
| "qtr" | ||
| "quarter" | ||
| "doy" | ||
| "dow" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
second, millisecond, micro, nanos too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let r: Float64Array = secs
.iter()
.zip(subsecs)
.map(|(secs, subsecs)| {
secs.map(|secs| {
let subsecs = subsecs.unwrap_or(0);
(secs as f64 + ((subsecs % 1_000_000_000) as f64 / 1_000_000_000_f64))
* sf
})
})
.collect();
Probably we still need f64 for seconds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i didn't know extract(second ..
returns seconds with fraction. In PostgreSQL it does so, in e.g. Trino and Snowflake it does not
postgres=# select extract(second from now());
extract
-----------
29.009019
trino> select extract(second from now());
_col0
-------
46
so yes, keep seconds with float for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extract for seconds is float correct, returning the fractions. however its not the case for DuckDB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filed #13482 for seconds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jayzhan211 what about millisecond, micro, nano?
// Try to remove quote if exist, if the quote is invalid, return original string and let the downstream function handle the error | ||
fn part_normalization(part: &str) -> &str { | ||
part.strip_prefix(|c| c == '\'' || c == '\"') | ||
.and_then(|s| s.strip_suffix(|c| c == '\'' || c == '\"')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why would we want to support unmatched quotes like '..."
?
the date_part argument shouldn't contain any quotes, why would we want to support quotes at all?
i see this is pre-existing, so okay to keep, but still wonder why we're doing this, doesn't feel right
SELECT extract(year from arrow_cast('10 years', 'Interval(YearMonth)')) | ||
---- | ||
10 | ||
|
||
query R | ||
query I |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have explicit tests inspecting arrow_typeof(extract(....))
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I
is for integer and we don't need to make sure it is exactly i32 or i64 so I think that is fine. If we want to differentiate type like utf8 or utf8View then we need arrow_typeof
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since
I
is for integer
yes i know
need to make sure it is exactly i32 or i64
do we? do we not?
i think it may make difference, since it's 2x fewer bytes to keep in memory
up to you
|
Signed-off-by: jayzhan211 <[email protected]>
Co-authored-by: Daniël Heres <[email protected]>
Signed-off-by: jayzhan211 <[email protected]>
Signed-off-by: jayzhan211 <[email protected]>
return internal_err!("unit {unit:?} not supported"); | ||
} | ||
|
||
let conversion_factor = match unit { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably factor out the common part for this conversion in future. its too many hardcoded conversions between second fraction and corresponding long value in the project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm thanks @jayzhan211
Signed-off-by: Jay Zhan <[email protected]>
Thanks @comphead @findepi @Dandandan |
Which issue does this PR close?
Close #13482
Part of #13449
Rationale for this change
Date part such as year, month, day are integer type, we can return i32 instead of casting it to f64
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?