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*
