I made this change. It was a bit of a hack to re-use the non-deterministic property as an indication if a function could be folded into a constant.
If you look at the definition of that list of NON_REDUCIBLE_TYPES constant, explanations are given for why given types are included. The problem with the INTERVAL type is that Calcite did not allow creating a literal for this format. I believe this was intentional, so I didn't bother opening a Calcite JIRA. The issue is that our interval type spans across months and days, which I wasn't even sure how to interpret. I could not find an example of this type in other databases, see docs linked for examples in SQL Server and Oracle. [1] [2] Both of these systems support intervals that span across years and months or days/millis, and both of these Drill types are supported by the constant folding rule. [1] - http://docs.oracle.com/cd/E11882_01/server.112/e41084/sql_elements001.htm#SQLRF30020 [2] - https://msdn.microsoft.com/en-us/library/ms716506%28v=vs.85%29.aspx On Tue, Feb 2, 2016 at 6:11 AM, Jacques Nadeau <jacq...@dremio.com> wrote: > What jira was this change added with? > On Feb 1, 2016 11:42 PM, "Hsuan Yi Chu" <hyi...@maprtech.com> wrote: > >> All the variants of Negative DrillFuncHolder are supposed to be >> deterministic. However, when they are being registered >> into DrillOperatorTable, there is a if-statement: >> >> >> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/expr/fn/DrillFunctionRegistry.java#L116 >> >> which claims DrillFuncHolder being non-deterministic when return type is >> Interval. Why it is necessary to have this if-condition? >> >> ------------------------- >> >> Making DrillFuncHolder non-deterministic will prevent partition-pruing or >> constant folding from happening. >> >
