The UNION code attempts to figure a common data type and translate the data to that for comparison. In this case, the common data type is UNSIGNED, so the result is unsigned. Any result column can only have one data type. Our code will not support a different type for different rows. If we choose INT as the common type, the result would be incorrect for a different data set.

A potential fix is to choose a larger data type like BIGINT to hold the result. This would be large enough to handle the largest UNSIGNED and still handle negative numbers. It becomes a little more problematic if one of the types is UNSIGNED BIGINT. Perhaps we could do something with int128_t.

MariaDB chooses:

• DECIMAL(11,0) to mix INT andd INT UNSIGNED.
• DECIMAL(21,0) to mix BIGINT and BIGINT UNSIGNED.

I think CS should choose the same data types.

Build verified: 6.1.1 ( Drone #2585)

Reproduced the issue in build 2584 and verified the fix in build 2585.

MariaDB [mytest]> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected, 1 warning (0.116 sec)

MariaDB [mytest]> CREATE TABLE t1 (a INT, b INT UNSIGNED) ENGINE=ColumnStore;
Query OK, 0 rows affected (0.637 sec)

MariaDB [mytest]> INSERT INTO t1 VALUES (-1,1);
Query OK, 1 row affected (0.317 sec)

MariaDB [mytest]> SELECT * FROM (SELECT a FROM t1 UNION SELECT b FROM t1) tu;
------

------

------
2 rows in set (0.070 sec)