prestodb/presto · error · PrestoException

FUNCTION_IMPLEMENTATION_MISSING

FUNCTION_IMPLEMENTATION_MISSING

Error message

%s not found

What it means

Magic-literal functions are special functions bound to literal values (e.g. timestamp literals, decimal literals). When the manager tries to specialize such a function for the given signature and no matching implementation can be bound, it throws FUNCTION_IMPLEMENTATION_MISSING, indicating no registered implementation matches the requested signature.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/metadata/BuiltInTypeAndFunctionNamespaceManager.java:1400

            String typeName = signature.getNameSuffix().substring(MAGIC_LITERAL_FUNCTION_PREFIX.length());

            // lookup the type
            Type type = functionAndTypeManager.getType(parseTypeSignature(typeName));

            // verify we have one parameter of the proper type
            checkArgument(parameterTypes.size() == 1, "Expected one argument to literal function, but got %s", parameterTypes);
            Type parameterType = functionAndTypeManager.getType(parameterTypes.get(0));
            requireNonNull(parameterType, format("Type %s not found", parameterTypes.get(0)));

            return new SpecializedFunctionKey(
                    magicLiteralFunction,
                    BoundVariables.builder()
                            .setTypeVariable("T", parameterType)
                            .setTypeVariable("R", type)
                            .build(),
                    1);
        }
        throw new PrestoException(FUNCTION_IMPLEMENTATION_MISSING, format("%s not found", signature));
    }

    private static class EmptyTransactionHandle
            implements FunctionNamespaceTransactionHandle
    {
    }

    /**
     * TypeSignature but has overridden equals(). Here, we compare exact signature of any underlying distinct
     * types. Some distinct types may have extra information on their lazily loaded parents, and same parent
     * information is compared in equals(). This is needed to cache types in parametricTypesCache.
     */
    private static class ExactTypeSignature
    {
        private final TypeSignature typeSignature;

        public ExactTypeSignature(TypeSignature typeSignature)
        {

View on GitHub (pinned to 55bb57d202)

Solutions

1. Cast the literal explicitly to a supported type instead of relying on magic-literal resolution.
2. Check registered magic-literal function bindings; ensure the plugin providing the type is installed.
3. Rewrite the query to avoid the unsupported literal type.

Example fix

// before
SELECT 9999999999999999999999999999999999DECIMAL(5);
// after
SELECT CAST('9999999999999999999999999999999999' AS DECIMAL(38,0));

// avoid raw literals that require magic-literal specialization; prefer explicit CAST:
// CAST('123.45' AS DECIMAL(5,2)) instead of 123.45DECIMAL(5,2)

try { resolveFunction(signature); }
catch (PrestoException e) { if (e.getErrorCode().toErrorCodeCode() == FUNCTION_IMPLEMENTATION_MISSING.toErrorCode().getCode()) { rewriteQueryWithExplicitCast(); } else throw e; }

When it happens

Trigger: Resolving a magic-literal function signature (e.g. a literal of a type with no registered magic-literal implementation) during function specialization in doGetSpecializedFunctionKeyForMagicLiteralFunctions.

Common situations: Using a literal with an unusual or unsupported type (e.g. very large decimal, exotic varchar literal in a context requiring magic literal resolution); custom type plugins that don't register magic-literal bindings.

Related errors

• AMBIGUOUS_FUNCTION_CALL
• Failed to find matching function signature for %s, matching
• FUNCTION_NOT_FOUND
• INVALID_TABLE_PROPERTY
• ACCUMULO_TABLE_EXISTS

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