Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/517
The proximate cause of this particular issue is the mechanism by which the
cast function is being generated. As others have noted, the code is passing
through lines 316-316. My guess is that the materializer is working out how to
call this function:
Decimal28SparseFunctions.Decimal28SparseEqual( Decimal28Sparse left,
Decimal28Sparse right )
The materializer sees: D28SEqual( Decimal28Sparse, Integer )
The code wants to convert the Integer to a Decimal28Sparse. It asks the
argument for its precision and scale. But, since the argument just specifies
the "minor type" (SQL type), it does not have the extended attributes of
precision and scale. Thus, the annotations in the function definition are the
ultimate cause of the precision being 0:
@Param Decimal28SparseHolder left;
@Param Decimal28SparseHolder right;
Now, we might argue that the code should be using, as the target (p, s) the
(p,s) of the left argument (the one that is already a decimal). But, the
materializer does not know that this is an operator; it treats all functions
the same (operators and otherwise.) So, the materializer does not know that we
should treat arguments in this way. All it knows is that it has an Integer and
wants a D28S (of, presumably, any p & s).
Next, we can ask how DS28Equal handles the (p,s) of the two arguments: must
they be the same or can they be different? Looking at the code (as best as I
can tell), the code will align values with different (p,s) values. Thus, say,
values of Decimal28( 10, 2 ) and Decimal28( 8, 0 ) will compare properly.
So, back to the cast from Integer to D28S. As Dave suggests, we can
interpret (precision == 0) to mean "you figure it out": we can set (p,s) way we
want.
Dave's fix computes the precision based on the actual integer value. But,
since the comparison can handle any valid (p,s), we might as well set them to a
constant. Since the maximum Integer value is 2 billion, we can just use a
constant (10,0).
If the selected precision is constant, then the cost is low and the
solution is fine for both for constant integers (as in the original case), and
for per-row conversions (as in Aman's concern.)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
