Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11.15
-
None
-
None
Description
MDEV-34033 addressed the issue where the computed/stored column referenced other columns in the same table.
There is another issue that arises when the expression uses AND/OR. It seems that the expression is parsed/normalized in such a way that the non-semantic ordering of the conditionals is not consistent. However, the comparison function is order sensitive which causes the EXCHANGE PARTITION operation to fail with the 1736 Tables have different definitions.
I don't know if it would be better to have the parsed tree keep order, or to have the comparison be order agnostic.