[ https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16495886#comment-16495886 ]
Laurent Goujon edited comment on CALCITE-2303 at 5/30/18 11:42 PM: ------------------------------------------------------------------- I'm not suggesting a bug-compatibility mode, but at least a provision for a Calcite user (as in library user, but not necessarily end-user) to alter operands behaviour to match its needs. It's not a area of Calcite I know well for sure, but my impression is that the core of the implementation is around RexImpTable which is basically a singleton. Also, is Calcite always shadowing Postgres behaviour, which is considered the reference behavior? as for the behavior regarding DOW across database, sharing an internal analysis we did too: ||System||Syntax||Sun||Mon||Tues||Wed||Thurs||Fri||Sat||Comments|| |Dremio (old)|DAYOFWEEK(<DATE>)|7|1|2|3|4|5|6|...| |Dremio (old)|EXTRACT(DOW FROM <DATE>)|7|1|2|3|4|5|6|...| |Dremio (old)|DATE_PART('DOW', <DATE>)|7|1|2|3|4|5|6|...| |Dremio (old)|TO_CHAR(<DATE>, 'd')|7|1|2|3|4|5|6|...| |Dremio (new)|DAYOFWEEK(<DATE>)|1|2|3|4|5|6|7|...| |Dremio (new)|EXTRACT(DOW FROM <DATE>)|1|2|3|4|5|6|7|...| |Dremio (new)|DATE_PART('DOW', <DATE>)|1|2|3|4|5|6|7|...| |Dremio (new)|TO_CHAR(<DATE>, 'd')|1|2|3|4|5|6|7|...| |Oracle (USA)|TO_CHAR(DATE <DATE>, 'd')|1|2|3|4|5|6|7|Depends on NLS_TERRITORY: [https://tonyhasler.wordpress.com/2010/01/16/232/]| |PostgreSQL|TO_CHAR(DATE <DATE>, 'd')|1|2|3|4|5|6|7|...| |SQL Server|DATEPART(DW, <DATE>)|1|2|3|4|5|6|7|Customizable (US vs non US): [http://www.itprotoday.com/software-development/datefirst-and-datepart-relationship]| |MySQL|DAYOFWEEK(<DATE>)|1|2|3|4|5|6|7|[https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_dayofweek]| |Oracle (UK)|TO_CHAR(DATE <DATE>, 'd')|7|1|2|3|4|5|6|Depends on NLS_TERRITORY: [https://tonyhasler.wordpress.com/2010/01/16/232/]| |PostgreSQL|EXTRACT(ISODOW FROM DATE <DATE>)|7|1|2|3|4|5|6|[https://stackoverflow.com/questions/41181990/extract-day-of-week-from-date-field-in-postgresql-assuming-weeks-start-on-monday]| |PostgreSQL|EXTRACT(DOW FROM DATE <DATE>)|0|1|2|3|4|5|6|[https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT]| |PostgreSQL|DATE_PART('DOW', DATE <DATE>)|0|1|2|3|4|5|6|[https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT]| |MySQL|WEEKDAY(<DATE>)|6|0|1|2|3|4|5|[https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_week]| |DB2|EXTRACT(DOW FROM <DATE>)|1|2|3|4|5|6|7|[https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0053629.html]| |DB2|DAYOFWEEK(<DATE>[, <startofweek>])|1|2|3|4|5|6|7|default for startofweek is 1 (sunday) [https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000787.html]| |BigQuery|EXTRACT(DAYOFWEEK FROM <DATE>)|1|2|3|4|5|6|7|[https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#extract]| |PrestoDB|EXTRACT(DAY_OF_WEEK\|DOW FROM <DATE>)|1|2|3|4|5|6|7|[https://prestodb.io/docs/current/functions/datetime.html#day_of_week]| |Hive|EXTRACT(DAYOFWEEK FROM <DATE>)|1|2|3|4|5|6|7|[https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions]| |Vertica|EXTRACT(DOW FROM <DATE>)|0|1|2|3|4|5|6|[https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/EXTRACT.htm?Highlight=extract]| |Vertica|DATE_PART('DOW', <DATE>)|0|1|2|3|4|5|6|[https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/DATE_PART.htm?Highlight=extract]| |Vertica|TO_CHAR(<DATE>, 'D')|7|1|2|3|4|5|6|https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Formatting/TO_CHAR.htm?Highlight=extract| was (Author: laurentgo): I'm not suggesting a bug-compatibility mode, but at least a provision for a Calcite user (as in library user, but not necessarily end-user) to alter operands behaviour to match its needs. It's not a area of Calcite I know well for sure, but my impression is that the core of the implementation is around RexImpTable which is basically a singleton. Also, is Calcite always shadowing Postgres behaviour, which is considered the reference behavior? as for the behavior regarding DOW across database, sharing an internal analysis we did too: ||System||Syntax||Sun||Mon||Tues||Wed||Thurs||Fri||Sat||Comments|| |Dremio|DAYOFWEEK(<DATE>)|7|1|2|3|4|5|6|...| |Dremio|EXTRACT(DOW FROM <DATE>)|7|1|2|3|4|5|6|...| |Dremio|DATE_PART('DOW', <DATE>)|7|1|2|3|4|5|6|...| |Dremio|TO_CHAR(<DATE>, 'd')|7|1|2|3|4|5|6|...| |Oracle (USA)|TO_CHAR(DATE <DATE>, 'd')|1|2|3|4|5|6|7|Depends on NLS_TERRITORY: https://tonyhasler.wordpress.com/2010/01/16/232/| |PostgreSQL|TO_CHAR(DATE <DATE>, 'd')|1|2|3|4|5|6|7|...| |SQL Server|DATEPART(DW, <DATE>)|1|2|3|4|5|6|7|Customizable (US vs non US): http://www.itprotoday.com/software-development/datefirst-and-datepart-relationship| |MySQL|DAYOFWEEK(<DATE>)|1|2|3|4|5|6|7| https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_dayofweek| |Oracle (UK)|TO_CHAR(DATE <DATE>, 'd')|7|1|2|3|4|5|6|Depends on NLS_TERRITORY: https://tonyhasler.wordpress.com/2010/01/16/232/| |PostgreSQL|EXTRACT(ISODOW FROM DATE <DATE>)|7|1|2|3|4|5|6| https://stackoverflow.com/questions/41181990/extract-day-of-week-from-date-field-in-postgresql-assuming-weeks-start-on-monday| |PostgreSQL|EXTRACT(DOW FROM DATE <DATE>)|0|1|2|3|4|5|6| https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT| |PostgreSQL|DATE_PART('DOW', DATE <DATE>)|0|1|2|3|4|5|6| https://www.postgresql.org/docs/8.1/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT| |MySQL|WEEKDAY(<DATE>)|6|0|1|2|3|4|5| https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_week| |DB2|EXTRACT(DOW FROM <DATE>)|1|2|3|4|5|6|7| https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0053629.html| |DB2|DAYOFWEEK(<DATE>\[, <startofweek>\])|1|2|3|4|5|6|7| default for startofweek is 1 (sunday) https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000787.html| |BigQuery|EXTRACT(DAYOFWEEK FROM <DATE>)|1|2|3|4|5|6|7| https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#extract| |PrestoDB|EXTRACT(DAY_OF_WEEK\|DOW FROM <DATE>)|1|2|3|4|5|6|7| https://prestodb.io/docs/current/functions/datetime.html#day_of_week| |Hive|EXTRACT(DAYOFWEEK FROM <DATE>)|1|2|3|4|5|6|7| https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions| |Vertica|EXTRACT(DOW FROM <DATE>)|0|1|2|3|4|5|6| https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/EXTRACT.htm?Highlight=extract| |Vertica|DATE_PART('DOW', <DATE>)|0|1|2|3|4|5|6| https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Date-Time/DATE_PART.htm?Highlight=extract| |Vertica|TO_CHAR(<DATE>, 'D')|7|1|2|3|4|5|6|https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/Formatting/TO_CHAR.htm?Highlight=extract| > Support DECADE time unit in EXTRACT function > -------------------------------------------- > > Key: CALCITE-2303 > URL: https://issues.apache.org/jira/browse/CALCITE-2303 > Project: Calcite > Issue Type: Bug > Components: core > Reporter: Sergey Nuyanzin > Assignee: Julian Hyde > Priority: Major > Fix For: 1.17.0 > > > Here CALCITE-1177 were supported new units > however such test > {code:java} > @Test public void testDecadeFunction() throws Exception { > ExpressionChecker checker = new ExpressionChecker() > .addExpr("EXTRACT(DECADE FROM ts)", 199L) > ; > checker.buildRunAndCheck(); > } > {code} > failed like > Extract for time unit: DECADE not supported! > {noformat} > SQL:> > SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION > May 08, 2018 1:34:58 PM > org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner > validateAndConvert > INFO: SQL: > SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`) > FROM `PCOLLECTION` AS `PCOLLECTION` > May 08, 2018 1:34:58 PM > org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner > convertToBeamRel > INFO: SQLPlan> > LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)]) > BeamIOSourceRel(table=[[PCOLLECTION]]) > java.lang.RuntimeException: > org.apache.beam.sdk.Pipeline$PipelineExecutionException: > java.lang.UnsupportedOperationException: Extract for time unit: DECADE not > supported! > at > org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167) > at > org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at > com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) > at > com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) > at > com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) > at > com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) > Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException: > java.lang.UnsupportedOperationException: Extract for time unit: DECADE not > supported! > at > org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349) > at > org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319) > at > org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210) > at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66) > at org.apache.beam.sdk.Pipeline.run(Pipeline.java:311) > at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:346) > at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:328) > at > org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:165) > ... 25 more > Caused by: java.lang.UnsupportedOperationException: Extract for time unit: > DECADE not supported! > at > org.apache.beam.sdk.extensions.sql.impl.interpreter.operator.date.BeamSqlExtractExpression.evaluate(BeamSqlExtractExpression.java:92) > at > org.apache.beam.sdk.extensions.sql.impl.interpreter.BeamSqlFnExecutor.execute(BeamSqlFnExecutor.java:505) > at > org.apache.beam.sdk.extensions.sql.impl.transform.BeamSqlProjectFn.processElement(BeamSqlProjectFn.java:57) > {noformat} > I guess here _org.apache.calcite.avatica.util.DateTimeUtils#julianExtract_ > should be added something like > {code:java} > case DECADE: > return year > 0 > ? (year + 9) / 10 > : (year - 9) / 10; > {code} > or do I do something not right? -- This message was sent by Atlassian JIRA (v7.6.3#76005)