prestodb/presto · error · InvalidFunctionArgumentException

CHAR length scale must be in range [0, %s]

Error message

CHAR length scale must be in range [0, %s]

What it means

CharType's constructor validates the CHAR(n) length parameter when building the type from a TypeSignature. If the length is negative or exceeds MAX_LENGTH, the type cannot be represented, so it throws InvalidFunctionArgumentException immediately rather than constructing an invalid type. This guards the type registry against malformed CHAR definitions from catalogs, connectors, or SQL like CHAR(-1) or CHAR(99999999).

Source

Thrown at presto-common/src/main/java/com/facebook/presto/common/type/CharType.java:50

    public static final int MAX_LENGTH = 65_536;

    private final int length;

    public static CharType createCharType(long length)
    {
        return new CharType(length);
    }

    private CharType(long length)
    {
        super(
                new TypeSignature(
                        StandardTypes.CHAR,
                        singletonList(TypeSignatureParameter.of(length))),
                Slice.class);

        if (length < 0 || length > MAX_LENGTH) {
            throw new InvalidFunctionArgumentException(format("CHAR length scale must be in range [0, %s]", MAX_LENGTH));
        }
        this.length = (int) length;
    }

    public int getLength()
    {
        return length;
    }

    @Override
    public boolean isComparable()
    {
        return true;
    }

    @Override
    public boolean isOrderable()
    {

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Clamp or reject CHAR lengths at the connector/catalog level so only 0..MAX_LENGTH reach type creation
  2. Fix the column metadata source (e.g. unknown length mapped to -1) to emit a valid length or fall back to VARCHAR
  3. Validate user SQL CHAR(n) lengths before type resolution
  4. If MAX_LENGTH is genuinely too small for your data, use VARCHAR instead of CHAR

Example fix

// before
Type charType = typeManager.getParameterizedType(StandardTypes.CHAR, ImmutableList.of(TypeSignatureParameter.of(columnLength)));
// after
int safeLength = (columnLength < 0 || columnLength > CharType.MAX_LENGTH) ? CharType.MAX_LENGTH : (int) columnLength;
Type charType = typeManager.getParameterizedType(StandardTypes.CHAR, ImmutableList.of(TypeSignatureParameter.of(safeLength)));
Defensive patterns

Strategy: validation

Validate before calling

public static boolean isValidCharLength(long length) {
    return length >= 0 && length <= CharType.MAX_LENGTH;
}
// call: if (!isValidCharLength(len)) coerce or reject before createType

Type guard

public static boolean isUsableCharLength(Long length) {
    return length != null && length >= 0 && length <= CharType.MAX_LENGTH;
}

Try / catch

try {
    Type t = typeManager.getParameterizedType(StandardTypes.CHAR, ImmutableList.of(TypeSignatureParameter.of(length)));
} catch (InvalidFunctionArgumentException e) {
    // fall back to VARCHAR or clamp length and retry
}

Prevention

When it happens

Trigger: Calling CharType.createType(length) or constructing CharType via TypeRegistry with length < 0 or length > MAX_LENGTH (typically 65536); a connector/catalog metadata declares a CHAR column with an out-of-range length.

Common situations: Metadata drift between a connector's declared column types and Presto's CHAR limits; user SQL with an extreme CHAR(n); auto-generated schemas computing length as -1 when a column length is unknown.

Related errors


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