Observations while providing explicit cast functions. 1. On hitting any explicit cast query on Sqlline I get the below results. While debugging the flow I see that there is no lookup happening in FunctionImplementationRegistry for CAST() function, and therefore it is not casting the argument and returning the passed argument directly. It seems like some part of query validation is bypassing the lookup for 'cast' function from FunctionRegistry.
0: jdbc:drill:schema=parquet-local> select cast(2.3 as int) from "sample-data/region.parquet"; +---------+ | EXPR$0 | +---------+ | 2.3 | | 2.3 | | 2.3 | | 2.3 | | 2.3 | +---------+ 5 rows selected (0.489 seconds) 2. For the 'Is Castable' check, we might have to create our own class similar to Optiq's SqlAssignmentRules. Since Drill's datatypes are different from those used in Optiq we might not be able to reuse the class directly. (Ref: https://github.com/julianhyde/optiq/blob/master/core/src/main/java/org/eigenbase/sql/type/SqlTypeAssignmentRules.java) Alternatively, an approach can be adopted from Hive's org.apache.hadoop.hive.ql.exec.FunctionRegistry's implicitConvertable() method. It uses datatype grouping via enum (PrimitiveGrouping). Then implicitlyConvertable() method checks the common groups to check if types are convertible implicitly. Let me know your thoughts on the two approaches. Regards, Yash ________________________________________ From: Julian Hyde [[email protected]] Sent: Friday, November 22, 2013 4:16 AM To: [email protected] Subject: Re: hangout On Nov 20, 2013, at 9:12 PM, Jinfeng Ni <[email protected]> wrote: > 5. Nullable vs Non-nullable. I think implicit cast probably need > support cast from Non-nullable exp > > Nullable exp. Otherwise, for each operator and each type, we at least > have to implement 4 versions: > > 1) Nullable int + Nullable int > > 2) Nullable int + Non-Nullalbe int > > 3) Non-Nullable int + Nullable int > > 4) Non-Nullable int + Non-Nullalbe int. > > By implicit cast Non-nullable exp into Nullable exp, we only need > define one version: Nullable int + Nullable int. > . How to handle the null input could be specified in > function/operator's implementation. I faced this issue in Optiq's code generation. Since a lot of SQL operators generate null if any of their inputs are null, and since Optiq uses primitive types if it knows an expression cannot be null, I decided to implement only one version: Not-Nullable int + Not-Nullable int. If either argument is nullable, I add code around it to check for null values first. Thus: Integer x; Integer y; if (x == null) { return null; } else { int x_ = x; if (y == null) { return null; } else { int y_ = y; return x_ + y_; // this line is the only one produced by the implementor for '+' } } You can see the gory details in RexToLixTranslator. In the "Expression translate(RexNode expr, RexImpTable.NullAs nullAs)" method, nullAs says whether null should cause the method to return null, true (for implementing "x is null"), false, or whether null is simply not possible (because we've already dealt with the possibility of nulls. The supporting implementors (that do code generation for each operator or function) are in RexImpTable. Julian ________________________________ NOTE: This message may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee. If received in error, please destroy and notify the sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant and/or guarantee, that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference.
