prestodb/presto · error · PrestoException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

Unsupported type parameters (%s) for %s

What it means

ParametricScalar.specialize binds declared type variables to concrete types and picks an implementation among registered signatures. When no implementation matches the given type parameters (boundVariables), the engine throws NOT_SUPPORTED with the attempted binding and the function signature.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/operator/scalar/ParametricScalar.java:122

                checkCondition(selectedImplementation == null, AMBIGUOUS_FUNCTION_IMPLEMENTATION, "Ambiguous implementation for %s with bindings %s", getSignature(), boundVariables.getTypeVariables());
                selectedImplementation = scalarFunctionImplementation.get();
            }
        }
        if (selectedImplementation != null) {
            return selectedImplementation;
        }
        for (ParametricScalarImplementation implementation : implementations.getGenericImplementations()) {
            Optional<BuiltInScalarFunctionImplementation> scalarFunctionImplementation = implementation.specialize(boundSignature, boundVariables, functionAndTypeManager);
            if (scalarFunctionImplementation.isPresent()) {
                checkCondition(selectedImplementation == null, AMBIGUOUS_FUNCTION_IMPLEMENTATION, "Ambiguous implementation for %s with bindings %s", getSignature(), boundVariables.getTypeVariables());
                selectedImplementation = scalarFunctionImplementation.get();
            }
        }
        if (selectedImplementation != null) {
            return selectedImplementation;
        }

        throw new PrestoException(NOT_SUPPORTED, format("Unsupported type parameters (%s) for %s", boundVariables, getSignature()));
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Cast arguments to supported types explicitly (CAST the complex type to a supported one, e.g. cast(row(...) AS row(a integer, b varchar))).
2. Check the function's declared signature/type parameters and pass matching types.
3. Break nested types apart (explode/unnest) so scalar functions operate on supported element types.
4. Upgrade Presto if a newer version added the missing specialization.

Example fix

// before
SELECT my_scalar_fn(map_value); -- map_value is map(varchar, row(...))
// after
SELECT my_scalar_fn(CAST(map_value AS MAP(VARCHAR, VARCHAR)));

-- verify argument types match a supported specialization before calling
cast(complex_value AS MAP(VARCHAR, VARCHAR))

BEGIN try(CAST(x AS target_type)) ... END; -- or catch NOT_SUPPORTED and cast/fallback

When it happens

Trigger: Invoking a parametric scalar function with type arguments for which no registered specialization exists — e.g. map(array(varchar), row(...)) passed to a function only declared for primitive value types, or a nested/complex type the function's @TypeParameter constraints exclude.

Common situations: Calling scalar functions on complex types they were never declared for (raw rows, arrays of arrays when only flat types are supported), or after a type change in the schema (e.g. column became varchar vs integer) that no longer matches a specialization.

Understand the failure class

Background: Presto NOT_SUPPORTED error: what "not supported" means and how to fix it — this error's family across 3 libraries.

Related errors

• NOT_SUPPORTED
• NOT_SUPPORTED
• NOT_SUPPORTED
• NOT_SUPPORTED
• INVALID_TABLE_PROPERTY

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