Optimized away later. In fact during SQL generation. SQL has no concept of “casting away nullability”.
> On Aug 23, 2017, at 6:10 PM, Christian Beikov <christian.bei...@gmail.com> > wrote: > > RelOptMaterialization creates the cast which calls eventually into > RexUtil.generateCastExpressions. That method, probably rightfully, is strict > about nulls. The question is, whether the cast should be optimized away later > or it shouldn't be created in the first place. What do you say? > > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 24.08.2017 um 02:05 schrieb Julian Hyde: >> You didn’t say that the casts were ending up in generated SQL. That would be >> a bug. Probably in RelToSqlConverter. >> >> >>> On Aug 23, 2017, at 4:35 PM, Christian Beikov <christian.bei...@gmail.com> >>> wrote: >>> >>> I get that the cast is done "internally" to handle nulls properly, but why >>> would such a cast end up in the SQL that gets sent to the DBMS? Can you >>> point me to a direction where to look for these generated casts? I'd like >>> to try if I can avoid rendering these casts, as some DBMS planners might >>> get confused. >>> >>> >>> Mit freundlichen Grüßen, >>> ------------------------------------------------------------------------ >>> *Christian Beikov* >>> Am 23.08.2017 um 21:20 schrieb Julian Hyde: >>>> It’s difficult to say for sure whether the cast is necessary. For some of >>>> us consistency, is an end in itself. :) >>>> >>>> If a null was to occur, then yes, the cast would throw. But it’s also >>>> possible that Calcite can deduce that a null is impossible, in which case >>>> it wouldn’t even generate the logic. >>>> >>>> I have this argument with Ashutosh from time to time. He tends to say we >>>> can never be sure which expressions might or might not produce nulls, so >>>> why bother being so strict? I’d rather use every piece of information we >>>> can get, because it might allow us to optimize. >>>> >>>> By the way, there are cases where we can deduce that columns are >>>> not-nullable but we cannot change the row-type due to the RelOptRule >>>> contract. We ought to be generating RelMdPredicates in these cases. >>>> >>>> Julian >>>> >>>> >>>> >>>>> On Aug 23, 2017, at 11:33 AM, Christian Beikov >>>>> <christian.bei...@gmail.com> wrote: >>>>> >>>>> I am using materializations and my materialization table has nullable >>>>> columns. Calcite correctly determines that the underlying query can never >>>>> produce null for these columns, but I didn't encode that into the table >>>>> definitino. I was just wondering why the casts are generated in the SQL >>>>> that is sent to the owner of the materialization table. >>>>> >>>>> Thanks for the explanation, I suppose the cast causes proper exceptions >>>>> to be thrown when null is encountered instead of simply a NPE? Or is the >>>>> cast in such a case really unnecessary? >>>>> >>>>> >>>>> Mit freundlichen Grüßen, >>>>> ------------------------------------------------------------------------ >>>>> *Christian Beikov* >>>>> Am 23.08.2017 um 20:01 schrieb Julian Hyde: >>>>>> I presume you’re talking about RexNodes. It makes a lot of things easier >>>>>> if the argument to function call are EXACTLY the type required by that >>>>>> function. The system inserts implicit casts where necessary. >>>>>> >>>>>> If you’re generating Java code (in Enumerable convention) there is a lot >>>>>> of difference between INTEGER NOT NULL and INTEGER. The former can be >>>>>> represented by int, the latter only by java.lang.Integer. >>>>>> >>>>>> Julian >>>>>> >>>>>> >>>>>>> On Aug 23, 2017, at 2:08 AM, Christian Beikov >>>>>>> <christian.bei...@gmail.com> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I came to notice that the use of a nullable column in a context where a >>>>>>> non-nullable is expected, causes a cast that is essentially useless. Am >>>>>>> I missing something and is there reason to why that is done? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Mit freundlichen Grüßen, >>>>>>> ------------------------------------------------------------------------ >>>>>>> *Christian Beikov* >
