[
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)
