Re: question about implement a scalarFunction whose argument type is date or timestamp

now the null value of Date or Timestamp type columns could not be queried. the runtime exception is cannot convert null to long Using Integer or Long to represent Date and Timestamp may be a better choice? 2015-11-20 4:41 GMT+08:00 Julian Hyde : > You are definitely seeing a

Re: Changes for Grouping Sets in Calcite

Thanks for your quick reply Julian. Although I do not feel too strongly about one choice or another, I think we could use a single type, as it will simplify the GROUPING_ID and GROUPING functions implementation. However, I agree with you that we cannot limit the number of grouping columns.

Using Calcite for Apache Flink's higher-level languages

Hi Calcite Folks! The Apache Flink community is currently looking into how to use Calcite for optimization of both batch and streaming programs. We are looking to compile two different kinds of higher level APIs via Calcite to Flink's APIs: - Table API (a LINQ-style DSL) - SQL Our current

Re: Changes for Grouping Sets in Calcite

By “fail fast” I meant discovering rules that did not handle GROUPING_ID properly, without explicitly writing extra tests. By putting “g” at the start, all key and aggregate columns would be off-by-one, so it maximizes the chance of finding the problem (usually an assert due to a datatype

Re: compilation problem

Thanks Josh! It works. On Tue, Dec 8, 2015 at 9:00 PM, Josh Elser wrote: > Hi Pengcheng, > > The guidance is to use `mvn package` to build the code. The way the > dependencies currently are shared across Calcite maven modules does not > work with a `mvn compile` alone. > >

Re: question about implement a scalarFunction whose argument type is date or timestamp

Calcite uses int, int, long to represent DATE, TIME, TIMESTAMP (respectively) if they are NOT NULL, and Integer, Integer, Long to represent them if they are nullable. It seems likely that Calcite is deducing that the return type of the UDF is DATE NOT NULL. This is incorrect: it should be

Re: A question regarding the INTERVAL_DAY_TIME

What would you expect the following to yield? VALUES CAST(INTERVAL '3' HOUR AS INTEGER) Like all intervals (except year-month intervals) the interval is internally represented in milliseconds, in this case 10,800,000, but when converted to a string or a numeric it is measured in hours, i.e. 3.

A question regarding the INTERVAL_DAY_TIME

Hi all, While I was trying to debug something in Hive, I found some code in RexBuilder which makes me confused. L527 it says {code} final long multiplier = literal.getType().getIntervalQualifier().getStartUnit() .multiplier; {code} I saw it was

Re: A question regarding the INTERVAL_DAY_TIME

Remember that that piece of code is used only for literals. The value used at run time might be represented differently than how it is represented in the literal. That piece of code optimizes casts. So if you write CAST(3 AS INTERVAL MINUTE) - i.e. convert from an INTEGER literal to an INTERVAL