[ https://issues.apache.org/jira/browse/CALCITE-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762530#comment-17762530 ]
Mihai Budiu edited comment on CALCITE-5919 at 9/7/23 1:06 AM: -------------------------------------------------------------- This is also related to CALCITE-3529 was (Author: JIRAUSER295926): This is also related to https://issues.apache.org/jira/browse/CALCITE-3529 > Compile-time implementation of EXTRACT ignores sub-millisecond values > --------------------------------------------------------------------- > > Key: CALCITE-5919 > URL: https://issues.apache.org/jira/browse/CALCITE-5919 > Project: Calcite > Issue Type: Bug > Components: core > Affects Versions: 1.35.0 > Reporter: Mihai Budiu > Priority: Minor > > When enabling the optimization rule PROJECT_REDUCE_EXPRESSIONS the > compile-time evaluation of an expression like EXTRACT(MICROSECONDS FROM TIME > '13:30:25.575401') will produce a result up to milliseconds only, > irrespective of the type system provided. (This query will evaluate to > 25575000 instead of 25575401). > The bug is in RexImpTable.ExtractImplementor, here: > {code:java} > case MILLISECOND: > case MICROSECOND: > case NANOSECOND: > if (sqlTypeName == SqlTypeName.DATE) { > return Expressions.constant(0L); > } > operand = mod(operand, TimeUnit.MINUTE.multiplier.longValue(), > !isIntervalType); // << BUG > return Expressions.multiply( > operand, Expressions.constant((long) (1 / > unit.multiplier.doubleValue()))); > {code} > The mod operation uses a multiplier for MINUTE that is expressed in > milliseconds, so it always truncates away values below milliseconds. The > multiplier seems to assume that the type system precision for TIME is set to > 3, which is the default value, but may be overridden. -- This message was sent by Atlassian Jira (v8.20.10#820010)