prestodb/presto · error · UnsupportedOperationException

getObjectValue is not supported for TIMESTAMP(

Error message

getObjectValue is not supported for TIMESTAMP(

What it means

Type.getObjectValue returns a Java object representation of a block value, but TimestampType only supports that materialization for the default precision (3) and MAX_SHORT_PRECISION (6). Other precisions (including long precisions 7-12) lack a supported Object representation, so UnsupportedOperationException is thrown.

Source

Thrown at presto-common/src/main/java/com/facebook/presto/common/type/TimestampType.java:117

        if (precision == MAX_SHORT_PRECISION) {
            // Preserve "timestamp microseconds" for the same reason.
            return parseTypeSignature(StandardTypes.TIMESTAMP_MICROSECONDS);
        }
        // Other precisions use a numeric parameter; the type registry does not yet recognize the
        // "timestamp(p)" string form, so these instances are created directly rather than parsed.
        return new TypeSignature(StandardTypes.TIMESTAMP, TypeSignatureParameter.of((long) precision));
    }

    // Only p=3 and p=6 are supported; all other precisions throw UnsupportedOperationException.
    // Support for p=0–2, p=4–5, and p=7–12 is planned for a follow-up change.
    @Override
    public Object getObjectValue(SqlFunctionProperties properties, Block block, int position)
    {
        if (block.isNull(position)) {
            return null;
        }
        if (precision != DEFAULT_PRECISION && precision != MAX_SHORT_PRECISION) {
            throw new UnsupportedOperationException(
                    "getObjectValue is not supported for TIMESTAMP(" + precision + ")");
        }
        TimeUnit unit = toTimeUnit(precision);
        if (properties.isLegacyTimestamp()) {
            return new SqlTimestamp(block.getLong(position), properties.getTimeZoneKey(), unit);
        }
        return new SqlTimestamp(block.getLong(position), unit);
    }

    // True when the value fits in a single long (p <= MAX_SHORT_PRECISION). Storage concept only —
    // short precisions other than p=3 and p=6 are not yet registered in the type manager.
    public boolean isShort()
    {
        return precision <= MAX_SHORT_PRECISION;
    }

    // Used to distinguish millisecond-precision timestamps (e.g. PartitionTable Iceberg partition
    // value conversion, and future JDBC/ORC paths).

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Use getLong / getSlice (the packed long representation) instead of getObjectValue for TIMESTAMP columns.
  2. For p=3 or p=6 columns, no change is needed; for others convert via toEpochMillis/toEpochMicros when isShort() is true.
  3. Switch queries/consumers to TIMESTAMP(3) or TIMESTAMP(6) if an Object value is required.
  4. Check precision via type.getPrecision() before calling getObjectValue and handle unsupported precisions explicitly.

Example fix

// before
Object v = timestampType.getObjectValue(properties, block, position);
// after
Object v = (timestampType.getPrecision() == 3 || timestampType.getPrecision() == 6)
        ? timestampType.getObjectValue(properties, block, position)
        : timestampType.getLong(block, position);
Defensive patterns

Strategy: type-guard

Validate before calling

if (type instanceof TimestampType
        && ((TimestampType) type).getPrecision() != 3
        && ((TimestampType) type).getPrecision() != 6) {
    throw new IllegalStateException("Use getLong for TIMESTAMP(" + ((TimestampType) type).getPrecision() + ")");
}

Type guard

boolean supportsObjectValue(TimestampType t) { return t.getPrecision() == 3 || t.getPrecision() == 6; }

Try / catch

try {
    value = timestampType.getObjectValue(props, block, pos);
} catch (UnsupportedOperationException e) {
    value = timestampType.getLong(block, pos); // packed representation
}

Prevention

When it happens

Trigger: Calling getObjectValue(properties, block, position) on a TIMESTAMP(p) type where p is not 3 and not 6 (e.g. TIMESTAMP(0), TIMESTAMP(9), TIMESTAMP(12)) on a non-null position.

Common situations: Generic result-set materialization code in clients/JDBC layers or connectors that iterate all types and call getObjectValue without checking the precision; new long-precision TIMESTAMP columns appearing after a version upgrade.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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