prestodb/presto · error · UnsupportedOperationException

fieldType.getTypeSignature() + " type is not orderable"

Error message

fieldType.getTypeSignature() + " type is not orderable"

What it means

RowType's row comparison requires every field type to be orderable. During compareTo, if the field at the current position has isOrderable() == false, UnsupportedOperationException("<signature> type is not orderable") is thrown. Rows containing unorderable element types (e.g. maps, rows containing maps) cannot be compared for <, >, sorting.

Source

Thrown at presto-common/src/main/java/com/facebook/presto/common/type/RowType.java:319

                return false;
            }
        }

        return true;
    }

    @Override
    public int compareTo(Block leftBlock, int leftPosition, Block rightBlock, int rightPosition)
    {
        Block leftRow = leftBlock.getBlock(leftPosition);
        Block rightRow = rightBlock.getBlock(rightPosition);

        for (int i = 0; i < leftRow.getPositionCount(); i++) {
            checkElementNotNull(leftRow.isNull(i));
            checkElementNotNull(rightRow.isNull(i));
            Type fieldType = fields.get(i).getType();
            if (!fieldType.isOrderable()) {
                throw new UnsupportedOperationException(fieldType.getTypeSignature() + " type is not orderable");
            }
            int compareResult = fieldType.compareTo(leftRow, i, rightRow, i);
            if (compareResult != 0) {
                return compareResult;
            }
        }

        return 0;
    }

    @Override
    public long hash(Block block, int position)
    {
        Block arrayBlock = block.getBlock(position);
        long result = 1;
        for (int i = 0; i < arrayBlock.getPositionCount(); i++) {
            Type elementType = fields.get(i).getType();
            result = 31 * result + TypeUtils.hashPosition(elementType, arrayBlock, i);

View on GitHub (pinned to 55bb57d202)

Solutions

Restrict comparisons to rows whose fields are all orderable (primitives, strings, arrays of orderable types).
Reorder comparison so unorderable fields are compared element-wise manually via type-specific functions (e.g. map_keys).
Use hash-based equality/distinct instead of ordering when fields are only hashable but not orderable.

Example fix

// before
ORDER BY row_col
// after
ORDER BY row_col["orderable_field"], map_keys(row_col.m) -- avoid comparing map field directly

Defensive patterns

Strategy: type-guard

Validate before calling

for (RowType.Field f : rowType.getFields()) { if (!f.getType().isOrderable()) throw new IllegalArgumentException("unorderable field"); }

Type guard

boolean isOrderableRow(RowType t) { return t.getFields().stream().allMatch(f -> f.getType().isOrderable()); }

Try / catch

try { rowType.compareTo(left, right); } catch (UnsupportedOperationException e) { /* use element-wise or hash comparison instead */ }

Prevention

Avoid ORDER BY / min-max on ROW columns containing MAP or other unorderable types.
Check Type.isOrderable() before registering comparators in custom operators.
Prefer equality (DISTINCT) via hash semantics when ordering is not required.

When it happens

Trigger: Calling RowType.compareTo (or equality/ordering machinery) on a row whose field type is not orderable, e.g. ORDER BY on a column containing MAP elements or ROWs with map fields.

Common situations: ORDER BY or min/max on row-typed columns with map members; GROUP BY with row keys containing maps; comparator-based operators receiving nested unorderable types.

Related errors

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