Comparison data type aggregation is done when we need to mix two or more expressions of different data types for comparison.
Examples:

SELECT a=b FROM t1;

SELECT a BETWEEN b AND c FROM t1;

SELECT a IN (b,c) FROM t1;

SELECT CASE predicant WHEN expr1 THEN ... WHEN expr2 THEN ... END FROM t1;

Functions LEAST and GREATEST are out of scope of this task and will be done separately.

Comparing of any arbitrary general purpose data types (like INT, DOUBLE, VARCHAR) was OK. But as we'll be adding special purpose data types like INET6, some mixtures will be meaningless. For example, comparing INET6 with TIME does not seem to have any sense.

New data type implementations should be able to decide:
1. to which other data types it can be compared with, or cannot be compared with (with a possibility to raise an error if comparison is not possible)
2. which data type format (handler) is used for comparison, if comparison is possible

Under terms of this tasks we'll implement a special registry which will contain the above information. Later, when we implement data type plugins, the server will add mixing rules to this registry when loading a new data type plugin.

The patch for this task will not change behavior for the existing data types.

The only exception is GEOMETRY, which is not a general purpose data type. We will change GEOMETRY to use the new comparison data type aggregation registry. Meaningless mixtures of GEOMETRY with other data types will be disallowed.