prestodb/presto · error · PrestoException
NOT_SUPPORTED
NOT_SUPPORTED
Error message
Unsupported coercion from %s to %s
What it means
HiveCoercionRecordCursor.createCoercer is the cursor-level twin of HiveCoercer.createCoercer, used when reading old files after a column type change and bridging values through a RecordCursor; it supports integer upscaling, varchar<->integer, float->double, and recursive list/map/struct coercions. Any other from/to combination throws NOT_SUPPORTED, since Presto cannot convert the on-disk values to the new declared column type.
Source
Thrown at presto-hive/src/main/java/com/facebook/presto/hive/HiveCoercionRecordCursor.java:313
return new IntegerNumberUpscaleCoercer();
}
else if (fromHiveType.equals(HIVE_INT) && toHiveType.equals(HIVE_LONG)) {
return new IntegerNumberUpscaleCoercer();
}
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, bridgingRecordCursor);
}
else if (isMapType(fromType) && isMapType(toType)) {
return new MapCoercer(typeManager, fromHiveType, toHiveType, bridgingRecordCursor);
}
else if (isRowType(fromType) && isRowType(toType)) {
return new StructCoercer(typeManager, fromHiveType, toHiveType, bridgingRecordCursor);
}
throw new PrestoException(NOT_SUPPORTED, format("Unsupported coercion from %s to %s", fromHiveType, toHiveType));
}
private static class IntegerNumberUpscaleCoercer
extends Coercer
{
@Override
public void coerce(RecordCursor delegate, int field)
{
setLong(delegate.getLong(field));
}
}
private static class IntegerNumberToVarcharCoercer
extends Coercer
{
@Override
public void coerce(RecordCursor delegate, int field)
{View on GitHub (pinned to 55bb57d202)
Solutions
- Physically rewrite the data with explicit casts: CREATE TABLE t_new AS SELECT CAST(col AS <new_type>) ... then swap, so no read-time coercion is needed.
- Restrict the ALTER to coercion-supported transitions (tinyint/smallint/int->larger ints, int types->varchar, varchar->integer types, float->double, and element-wise compatible array/map/struct changes).
- For nested types, evolve each element/field type only to supported coercions (e.g. array<int> -> array<bigint>), otherwise rewrite the column via INSERT OVERWRITE with casts.
Example fix
-- before: unsupported read-time coercion after ALTER ALTER TABLE t CHANGE COLUMN s s DECIMAL(10,2); SELECT * FROM t; -- fails: Unsupported coercion from varchar to decimal(10,2) -- after: rewrite data with explicit cast CREATE TABLE t_new AS SELECT CAST(s AS DECIMAL(10,2)) AS s FROM t; -- drop t, rename t_new to t
Defensive patterns
Strategy: validation
Validate before calling
-- before changing a column type that old files must read through, verify the pair is supported: -- integer upscale (tinyint/smallint/int -> larger ints), int<->varchar, float -> double, -- array->array / map->map / row->row with supported element/field coercions. -- Otherwise plan a CTAS rewrite with explicit CASTs.
Try / catch
try { ResultSet rs = stmt.executeQuery("SELECT * FROM evolved_table"); ... }
catch (SQLException e) {
if (e.getMessage() != null && e.getMessage().contains("Unsupported coercion from")) {
// rewrite old partitions with explicit casts, then retry the query
} else throw e;
} Prevention
- After ALTERing column types, immediately rewrite all old partitions so no legacy-schema files remain.
- Evolve nested (array/map/struct) element and field types only to supported coercions.
- Test the read path on a copy of an old partition before promoting schema changes to production.
- Keep a type-evolution compatibility checklist next to your migration runbooks.
When it happens
Trigger: Querying a Hive table after ALTER TABLE changed a column to a type outside the supported coercion set (e.g. string->date/timestamp/boolean/decimal, int->double/real, tinyint->float), where the read path goes through HiveCoercionRecordCursor with a bridging record cursor; also unsupported nested element/field coercions inside array/map/struct columns.
Common situations: Schema evolution altering string columns to date/decimal/boolean; converting int to double/float; struct field type changes to unsupported targets; then running a SELECT over partitions still containing files written with the old schema.
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
- HIVE_BAD_DATA
- Unsupported column type:
- Expected field to be %s, actual %s (field %s)
- NOT_SUPPORTED
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/087d316cab924efa.
Report an issue: GitHub.