prestodb/presto · error · IllegalArgumentException

unsupported type ${columnType}

Error message

unsupported type ${columnType}

What it means

Inside ISO8601JsonFieldDecoder.getLong, after handling the supported types (TIMESTAMP, TIME with zone, DATE), any remaining column type reaches an explicit IllegalArgumentException("unsupported type " + columnType). The ISO8601 dataFormat cannot serve that column type; the decoder surface simply doesn't support it. This is a configuration/column-type misuse rather than bad row data.

Source

Thrown at presto-record-decoder/src/main/java/com/facebook/presto/decoder/json/ISO8601JsonFieldDecoder.java:128

                }
                if (columnType == TIMESTAMP_WITH_TIME_ZONE) {
                    // Equivalent to:
                    // ZonedDateTime dateTime = ISO_OFFSET_DATE_TIME.parse(textValue, ZonedDateTime::from);
                    // packDateTimeWithZone(dateTime.toInstant().toEpochMilli(), getTimeZoneKey(dateTime.getZone().getId()));
                    TemporalAccessor parseResult = ISO_OFFSET_DATE_TIME.parse(textValue);
                    return packDateTimeWithZone(parseResult.getLong(INSTANT_SECONDS) * 1000 + parseResult.getLong(MILLI_OF_SECOND), getTimeZoneKey(ZoneId.from(parseResult).getId()));
                }
                if (columnType == TIME) {
                    return ISO_TIME.parse(textValue).getLong(MILLI_OF_DAY);
                }
                if (columnType == TIME_WITH_TIME_ZONE) {
                    TemporalAccessor parseResult = ISO_OFFSET_TIME.parse(textValue);
                    return packDateTimeWithZone(parseResult.get(MILLI_OF_DAY), getTimeZoneKey(ZoneId.from(parseResult).getId()));
                }
                if (columnType == DATE) {
                    return ISO_DATE.parse(textValue).getLong(EPOCH_DAY);
                }
                throw new IllegalArgumentException("unsupported type " + columnType);
            }
            catch (DateTimeParseException e) {
                throw new PrestoException(
                        DECODER_CONVERSION_NOT_SUPPORTED,
                        format("could not parse value '%s' as '%s' for column '%s'", value.asText(), columnType, columnHandle.getName()));
            }
        }
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Change the column's type to a supported temporal type (DATE, TIME, TIME WITH TIME ZONE, TIMESTAMP) or remove dataFormat
  2. Remove the iso8601 dataFormat so the default decoder handles non-temporal types
  3. Fix the schema in the table definition DDL/JSON
  4. Catch the PrestoException wrapping GENERIC_USER_ERROR at decoder construction time

Example fix

// before
{"name":"ts","type":"varchar","dataFormat":"iso8601"}
// after
{"name":"ts","type":"timestamp","dataFormat":"iso8601"} or drop dataFormat
Defensive patterns

Strategy: validation

Validate before calling

java.util.Set<String> supported = java.util.Set.of("date","time","time with time zone","timestamp"); boolean ok = supported.contains(column.getType().getDisplayName().toLowerCase()) && "iso8601".equals(column.getDataFormat());

Try / catch

try { JsonFieldDecoder d = JsonRowDecoderFactory.create(...); } catch (PrestoException e) { if (e.getErrorCode().getCode() == StandardErrorCode.GENERIC_USER_ERROR.getCode()) { failFast(e.getMessage()); } else throw e; }

Prevention

When it happens

Trigger: Declaring a column with dataFormat 'iso8601' whose type is not TIMESTAMP/TIME/TIME WITH TIME ZONE/DATE — e.g. bigint, varchar, or a custom type — causing getLong to fall through to the unsupported-type branch.

Common situations: Copy-pasted table definitions where iso8601 was applied to a varchar or bigint column; connector upgrades that validate column types strictly at decode time.

Related errors

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