prestodb/presto · error · IllegalArgumentException

unsupported column type '%s' for column '%s' with data forma

Error message

unsupported column type '%s' for column '%s' with data format '%s'

What it means

The second branch of JsonRowDecoderFactory.throwUnsupportedColumnType fires when the column both has an unsupported type AND a dataFormat is set; the message includes the dataFormat to aid diagnosis. The JSON row decoder cannot produce that column type from that format combination.

Source

Thrown at presto-record-decoder/src/main/java/com/facebook/presto/decoder/json/JsonRowDecoderFactory.java:92

                case "rfc2822":
                    return new RFC2822JsonFieldDecoder(column);
                case "":
                    return new DefaultJsonFieldDecoder(column);
                default:
                    throw new IllegalArgumentException(format("unknown data format '%s' used for column '%s'", column.getDataFormat(), column.getName()));
            }
        }
        catch (IllegalArgumentException e) {
            throw new PrestoException(GENERIC_USER_ERROR, e);
        }
    }

    public static JsonFieldDecoder throwUnsupportedColumnType(DecoderColumnHandle column)
    {
        if (column.getDataFormat() == null) {
            throw new IllegalArgumentException(format("unsupported column type '%s' for column '%s'", column.getType().getDisplayName(), column.getName()));
        }
        throw new IllegalArgumentException(format("unsupported column type '%s' for column '%s' with data format '%s'", column.getType(), column.getName(), column.getDataFormat()));
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

Make the column type compatible with the dataFormat (e.g. timestamp/date/time for iso8601, bigint for milliseconds-since-epoch, varchar for rfc2822)
Remove the dataFormat if the default decoder is intended
Pick a dataFormat supported for the declared type
Validate type/format pairs against connector documentation

Example fix

// before
{"name":"ts","type":"varchar","dataFormat":"iso8601"}
// after
{"name":"ts","type":"timestamp","dataFormat":"iso8601"}

Defensive patterns

Strategy: validation

Validate before calling

boolean isoLike = java.util.Set.of("iso8601","rfc2822","custom-date-time","milliseconds-since-epoch").contains(column.getDataFormat()); boolean temporal = java.util.Set.of("date","time","time with time zone","timestamp","bigint","varchar").contains(column.getType().getDisplayName().toLowerCase()); boolean ok = !isoLike || temporal;

Try / catch

try { decoder = JsonRowDecoderFactory.create(...); } catch (PrestoException e) { if (e.getErrorCode().getCode() == StandardErrorCode.GENERIC_USER_ERROR.getCode()) { log.error("type/format mismatch: " + e.getMessage()); failFast(); } else throw e; }

Prevention

Maintain a type/dataFormat compatibility matrix in your config tooling
Change type and dataFormat together when editing definitions
Dry-run decoder construction in CI against every table definition
Consult connector docs for which formats support which types

When it happens

Trigger: A column with dataFormat (e.g. 'iso8601', 'custom-date-time') whose type is not a temporal/primitive type the format can produce — e.g. dataFormat 'rfc2822' on a bigint column with no matching decoder.

Common situations: Mismatched type/format pairs in topic definition JSON (e.g. iso8601 format on a varchar column); template edits that changed type but kept dataFormat.

Related errors

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