calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <christian.bei...@gmail.com>
Subject Re: Casts because of nullability differences
Date Wed, 23 Aug 2017 23:35:23 GMT
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.beikov@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.beikov@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*


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message