prestodb/presto · error · PrestoException

INVALID_ARGUMENTS

INVALID_ARGUMENTS

Error message

Type %s does not allow ordering

What it means

The greater-than (>) operator specialized for DISTINCT types requires the underlying type to be orderable. In specialize, if the bound type variable T is a DistinctType whose base type cannot be ordered, Presto throws INVALID_ARGUMENTS with the type's display name. Ordering a non-orderable type is undefined, so the engine refuses to resolve the comparison operator.

Source

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

        extends SqlOperator
{
    public static final DistinctTypeGreaterThanOperator DISTINCT_TYPE_GREATER_THAN_OPERATOR = new DistinctTypeGreaterThanOperator();

    private DistinctTypeGreaterThanOperator()
    {
        super(GREATER_THAN,
                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, 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. Cast to the base type for comparison: CAST(d1 AS baseType) > CAST(d2 AS baseType).
2. Define or recreate the DISTINCT type over an orderable base type.
3. Rewrite the comparison using explicit, well-defined criteria on the distinct type's fields.
4. If equality-only semantics are needed, use = or DISTINCT FROM instead of ordering operators.

Example fix

// before
SELECT * FROM t WHERE d_col > d_threshold; -- non-orderable distinct type
// after
SELECT * FROM t WHERE CAST(d_col AS bigint) > CAST(d_threshold AS bigint);

-- guard > usage: only apply when the type supports ordering
-- if (!distinctType.isOrderable()) rewrite comparison on base type

boolean canOrder(DistinctType t) {
    return t != null && t.isOrderable();
}

try { rows = query("SELECT * FROM t WHERE d_col > d_threshold"); } catch (PrestoException e) { if (e.getErrorCode().getName().equals("INVALID_ARGUMENTS")) { rows = query("SELECT * FROM t WHERE CAST(d_col AS " + baseType + ") > CAST(d_threshold AS " + baseType + ")"); } else { throw e; } }

When it happens

Trigger: Using d1 > d2 where d1/d2 have a DISTINCT type over a non-orderable base type (e.g. a distinct type over map/row with non-orderable members). Triggered during planning when the > operator is specialized for that type.

Common situations: Filtering or joining on distinct-typed columns whose base type lost orderability; schema migrations switching a distinct type's base type; ORDER BY/GROUP BY-adjacent comparisons on such columns.

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/fe2f09dc79ef47af. Report an issue: GitHub.