prestodb/presto · error · PrestoException

INVALID_ARGUMENTS

INVALID_ARGUMENTS

Error message

Type %s does not allow ordering

What it means

The greater-than-or-equal operator for DISTINCT types requires the distinct type's underlying base type to support ordering. During specialization, Presto checks whether the bound type variable T is orderable; if not, it cannot resolve a >= operator on the base type, so it throws INVALID_ARGUMENTS. This guards against comparing values of a type that defines no ordering semantics.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/operator/scalar/distinct/DistinctTypeGreaterThanOrEqualOperator.java:58

        extends SqlOperator
{
    public static final DistinctTypeGreaterThanOrEqualOperator DISTINCT_TYPE_GREATER_THAN_OR_EQUAL_OPERATOR = new DistinctTypeGreaterThanOrEqualOperator();

    private DistinctTypeGreaterThanOrEqualOperator()
    {
        super(GREATER_THAN_OR_EQUAL,
                ImmutableList.of(withVariadicBound("T", DISTINCT_TYPE)),
                ImmutableList.of(),
                parseTypeSignature(BOOLEAN),
                ImmutableList.of(parseTypeSignature("T"), parseTypeSignature("T")));
    }

    @Override
    public BuiltInScalarFunctionImplementation specialize(BoundVariables boundVariables, int arity, FunctionAndTypeManager functionAndTypeManager)
    {
        DistinctType type = (DistinctType) boundVariables.getTypeVariable("T");
        if (!type.isOrderable()) {
            throw new PrestoException(INVALID_ARGUMENTS, format("Type %s does not allow ordering", type.getDisplayName()));
        }
        Type baseType = type.getBaseType();
        FunctionHandle functionHandle = functionAndTypeManager.resolveOperator(GREATER_THAN_OR_EQUAL, fromTypes(baseType, baseType));

        return new BuiltInScalarFunctionImplementation(
                false,
                ImmutableList.of(valueTypeArgumentProperty(RETURN_NULL_ON_NULL), valueTypeArgumentProperty(RETURN_NULL_ON_NULL)),
                functionAndTypeManager.getJavaScalarFunctionImplementation(functionHandle).getMethodHandle(),
                Optional.empty());
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Check type.isOrderable() for the distinct type before using ordering operators like >=, <, <=, >
2. Use only equality-based comparisons (equals operator) for non-orderable distinct types
3. Cast the values to an orderable type or compare the underlying base-type values instead
4. Redefine the distinct type over an orderable base type

Example fix

// before
SELECT * FROM t WHERE my_distinct_col >= my_distinct_value; -- base type not orderable
// after
SELECT * FROM t WHERE CAST(my_distinct_col AS base_type) >= CAST(my_distinct_value AS base_type); -- or use equality

if (!distinctType.isOrderable()) { throw new IllegalArgumentException("Type " + distinctType.getDisplayName() + " does not allow ordering; use equality instead"); }

if (type instanceof DistinctType && ((DistinctType) type).isOrderable()) { /* safe to use ordering operators */ }

try { return functionAndTypeManager.resolveOperator(GREATER_THAN_OR_EQUAL, fromTypes(baseType, baseType)); } catch (PrestoException e) { if (e.getErrorCode().getCode() == INVALID_ARGUMENTS.toErrorCode().getCode()) { /* fall back to equality semantics */ } throw e; }

When it happens

Trigger: Invoking the greater_than_or_equal operator on a DISTINCT type whose base type is not orderable (e.g. a distinct type over a non-orderable type such as a map or complex type). The exception is raised in specialize() when boundVariables type variable 'T' resolves to a DistinctType whose isOrderable() returns false.

Common situations: Users define a distinct type over a non-orderable base type and then attempt to use >= comparisons or ORDER BY/GROUP BY/min-max operations that desugar to the ordering operator; schema evolution or version changes where a base type lost orderability.

Related errors

• INVALID_ARGUMENTS
• INVALID_ARGUMENTS
• INVALID_ARGUMENTS
• INVALID_ARGUMENTS
• INVALID_CAST_ARGUMENT

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/680358e6ee9b9b6c. Report an issue: GitHub.