mihaibudiu opened a new pull request, #4024: URL: https://github.com/apache/calcite/pull/4024
The bug fixed is the following: In a set operation (UNION, INTERSECTION, EXCEPT) the participating relations are supposed to have the same columns with the same types. The type of the result is inferred to be the wider of the participating types. This is correct. However, the types of the operands participating in the set operations need to be coerced to the output type. This part was missing. The fix has two parts: - in SetopOperandsTypeChecker the missing coercion has been introduced (the code was there, but wasn't called in most cases) - in AbstractTypeCoercion a check for useless casts has been strengthened. The comments on the check were right, but the implementation was wrong. The complete fix is only a few lines of code, but... unfortunately this change leads to many test failures, which had to be patched, 63 at my count. Some of the tests are obviously wrong, while the other are more subtle. I had to disable a couple which I couldn't actually fix (not because the results are wrong, but because the condition they were testing is no longer present in the test). Many tests that contain plans are very hard for humans to evaluate for correctness. I also had to change the typeSystem of BigQuery to use raggedUnionTypesToVarying, from empirical testing this seems to be right. (In fact, I suspect other dialects also needs this change, the default in Calcite is the opposite, which is very weird). This may also seemingly degrade the quality of some query plans, because they will contain casts that were not there previously. Unfortunately, these plans were wrong. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
