What causes "Unsupported coercion from %s to %s" in prestodb/presto?

Rewrite the affected data instead of coercing at read time: CREATE TABLE new AS SELECT CAST(col AS ) ... and swap tables, so files physically match the new schema.

prestodb/presto · error · PrestoException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

Unsupported coercion from %s to %s

What it means

HiveCoercer.createCoercer builds a Block-to-Block conversion when a Hive table's column type changes (schema evolution, e.g. via ALTER TABLE CHANGE COLUMN); only a fixed set of coercions is supported: integer upscaling (tinyint/smallint/int -> bigger ints), int types -> varchar, varchar -> integer types, float -> double, and element-wise array/map/struct coercions. Any other source/target combination reaches the terminal throw of NOT_SUPPORTED, meaning Presto cannot read old files with the new declared type.

Source

Thrown at presto-hive/src/main/java/com/facebook/presto/hive/HiveCoercer.java:106

            return new IntegerNumberUpscaleCoercer(fromType, toType);
        }
        else if (fromHiveType.equals(HIVE_INT) && toHiveType.equals(HIVE_LONG)) {
            return new IntegerNumberUpscaleCoercer(fromType, toType);
        }
        else if (fromHiveType.equals(HIVE_FLOAT) && toHiveType.equals(HIVE_DOUBLE)) {
            return new FloatToDoubleCoercer();
        }
        else if (isArrayType(fromType) && isArrayType(toType)) {
            return new ListCoercer(typeManager, fromHiveType, toHiveType);
        }
        else if (isMapType(fromType) && isMapType(toType)) {
            return new MapCoercer(typeManager, fromHiveType, toHiveType);
        }
        else if (isRowType(fromType) && isRowType(toType)) {
            return new StructCoercer(typeManager, fromHiveType, toHiveType);
        }

        throw new PrestoException(NOT_SUPPORTED, format("Unsupported coercion from %s to %s", fromHiveType, toHiveType));
    }

    class IntegerNumberUpscaleCoercer
            implements HiveCoercer
    {
        private final Type fromType;
        private final Type toType;

        public IntegerNumberUpscaleCoercer(Type fromType, Type toType)
        {
            this.fromType = requireNonNull(fromType, "fromType is null");
            this.toType = requireNonNull(toType, "toType is null");
        }

        @Override
        public Block apply(Block block)
        {
            BlockBuilder blockBuilder = toType.createBlockBuilder(null, block.getPositionCount());

View on GitHub (pinned to 55bb57d202)

Solutions

Rewrite the affected data instead of coercing at read time: CREATE TABLE new AS SELECT CAST(col AS <new_type>) ... and swap tables, so files physically match the new schema.
Choose a supported target type for the ALTER (e.g. tinyint->int->bigint, int->varchar, varchar->bigint, float->double) that createCoercer supports.
If a decimal/double/date conversion is genuinely needed, use an explicit INSERT OVERWRITE with CAST after creating the table with the new schema, ensuring no old-format files remain.

Example fix

-- before: read-time coercion that is unsupported
ALTER TABLE t CHANGE COLUMN c c DATE;

-- after: physically rewrite data with an explicit cast
CREATE TABLE t_new AS SELECT CAST(c AS DATE) AS c, ... FROM t;
-- then drop/rename t_new to t

Defensive patterns

Strategy: validation

Validate before calling

-- before ALTERing a column type, check it is a supported read-time coercion:
-- allowed: tinyint/smallint/int -> (larger) int types; int types -> varchar;
-- varchar -> tinyint/smallint/int/bigint; float -> double;
-- array/array, map/map, row/row with recursively supported element coercions.
SHOW COLUMNS FROM t;  -- confirm old and new types fall in the supported set, else rewrite data

Try / catch

try { ResultSet rs = stmt.executeQuery("SELECT * FROM t"); ... }
catch (SQLException e) {
  if (e.getMessage() != null && e.getMessage().contains("Unsupported coercion from")) {
    // rewrite the table with explicit CASTs instead of relying on read-time coercion
  } else throw e;
}

Prevention

Restrict ALTER TABLE type changes to the supported coercion set.
Prefer CTAS + INSERT with explicit CAST to physically rewrite data instead of lazy read-time coercion.
Document the supported Hive type-evolution matrix for your team.
After any type change, run a smoke SELECT over an old partition immediately.

When it happens

Trigger: Altering a Hive table column to a type outside the supported set — e.g. varchar -> varchar/date/timestamp/boolean, int -> double, tinyint -> float, changing array element types to anything unsupported, map key/value coercions not supported — then querying the table so existing files must be coerced at read time.

Common situations: Schema evolution via ALTER TABLE changing a column to an incompatible type (string to date, int to decimal, int to double); changing a struct field to an unsupported type; data written before the ALTER whose files are lazily coerced during a subsequent SELECT.

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

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