prestodb/presto · error · PrestoException

INVALID_FUNCTION_ARGUMENT

INVALID_FUNCTION_ARGUMENT

Error message

e.getMessage()

What it means

createType wraps DecimalType.createDecimalType calls; if those throw InvalidFunctionArgumentException (e.g. invalid precision/scale like scale > precision or non-positive precision), it is converted to a PrestoException with INVALID_FUNCTION_ARGUMENT whose message comes from the underlying exception.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/type/DecimalParametricType.java:55

    }

    @Override
    public Type createType(List<TypeParameter> parameters)
    {
        try {
            switch (parameters.size()) {
                case 0:
                    return DecimalType.createDecimalType();
                case 1:
                    return DecimalType.createDecimalType(parameters.get(0).getLongLiteral().intValue());
                case 2:
                    return DecimalType.createDecimalType(parameters.get(0).getLongLiteral().intValue(), parameters.get(1).getLongLiteral().intValue());
                default:
                    throw new IllegalArgumentException("Expected 0, 1 or 2 parameters for DECIMAL type constructor.");
            }
        }
        catch (InvalidFunctionArgumentException e) {
            throw new PrestoException(INVALID_FUNCTION_ARGUMENT, e.getMessage(), e);
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Ensure 1 <= precision <= 38 and 0 <= scale <= precision in the type declaration
2. Swap argument order if scale and precision were reversed: DECIMAL(20,10) not DECIMAL(10,20)
3. Validate parameters programmatically before building the type string

Example fix

// before
CAST(x AS DECIMAL(10,20))
// after
CAST(x AS DECIMAL(20,10))

boolean validDecimal(int precision, int scale) { return precision >= 1 && precision <= 38 && scale >= 0 && scale <= precision; }

try { type = DecimalParametricType.createType(symbols); } catch (PrestoException e) { if (e.getErrorCode().getCode() == StandardErrorCode.INVALID_FUNCTION_ARGUMENT.toErrorCode().getCode()) { /* prompt user for corrected DECIMAL(p,s) */ } else { throw e; } }

When it happens

Trigger: Declaring DECIMAL with illegal parameters, e.g. `DECIMAL(0)`, `DECIMAL(-5)`, `DECIMAL(10,20)` (scale > precision), via DDL, CAST, or a connector type mapping.

Common situations: Schema translation from other databases (e.g. NUMERIC with scale > precision); programmatic type generation with unvalidated user input; migration scripts with wrong precision order.

Related errors

• GENERIC_INTERNAL_ERROR
• NUMERIC_VALUE_OUT_OF_RANGE
• INVALID_FUNCTION_ARGUMENT
• INVALID_FUNCTION_ARGUMENT
• INVALID_CAST_ARGUMENT

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