What causes "getBlob" in prestodb/presto?

Use rs.getBytes(columnIndex) to read the VARBINARY value directly, or getBinaryStream(columnIndex) for streaming

prestodb/presto · error · SQLFeatureNotSupportedException

getBlob

Error message

getBlob

What it means

getBlob(int) returns a java.sql.Blob locator for binary large object data. Presto's PrestoResultSet does not support BLOB locators and always throws SQLFeatureNotSupportedException("getBlob"). Use getBytes()/getBinaryStream()/getBinaryObject for binary data instead.

Source

Thrown at presto-jdbc/src/main/java/com/facebook/presto/jdbc/PrestoResultSet.java:1109

    @Override
    public Object getObject(int columnIndex, Map<String, Class<?>> map)
            throws SQLException
    {
        throw new SQLFeatureNotSupportedException("getObject");
    }

    @Override
    public Ref getRef(int columnIndex)
            throws SQLException
    {
        throw new SQLFeatureNotSupportedException("getRef");
    }

    @Override
    public Blob getBlob(int columnIndex)
            throws SQLException
    {
        throw new SQLFeatureNotSupportedException("getBlob");
    }

    @Override
    public Clob getClob(int columnIndex)
            throws SQLException
    {
        throw new SQLFeatureNotSupportedException("getClob");
    }

    @Override
    public Array getArray(int columnIndex)
            throws SQLException
    {
        Object value = column(columnIndex);
        if (value == null) {
            return null;
        }

View on GitHub (pinned to 55bb57d202)

Solutions

Use rs.getBytes(columnIndex) to read the VARBINARY value directly, or getBinaryStream(columnIndex) for streaming
Change the code path to work with byte[] instead of java.sql.Blob
Check the column type via ResultSetMetaData and branch to the Presto-supported accessor

Example fix

// before
Blob blob = rs.getBlob("payload");
byte[] data = blob.getBytes(1, (int) blob.length());
// after
byte[] data = rs.getBytes("payload");
// or stream:
try (InputStream in = rs.getBinaryStream("payload")) { ... }

Defensive patterns

Strategy: fallback

Validate before calling

int type = rs.getMetaData().getColumnType(col);
if (type == java.sql.Types.VARBINARY || type == java.sql.Types.BINARY) {
    byte[] data = rs.getBytes(col); // instead of rs.getBlob(col)
}

Type guard

static boolean isBinaryColumn(ResultSetMetaData md, int col) throws SQLException {
    int t = md.getColumnType(col);
    return t == Types.VARBINARY || t == Types.BINARY || t == Types.LONGVARBINARY;
}

Try / catch

try {
    return rs.getBlob(col);
} catch (SQLFeatureNotSupportedException e) {
    byte[] bytes = rs.getBytes(col);
    return bytes == null ? null : new javax.sql.rowset.serial.SerialBlob(bytes);
}

Prevention

Use getBytes()/getBinaryStream() for Presto VARBINARY columns
Avoid java.sql.Blob/Clob APIs with Presto
Check ResultSetMetaData column types before choosing an accessor

When it happens

Trigger: Calling rs.getBlob(columnIndex) or getBlob(columnLabel) on a PrestoResultSet for a VARBINARY column.

Common situations: Code ported from MySQL/PostgreSQL drivers that store files in BLOB columns; document/image handling code assuming java.sql.Blob; ORMs mapping BLOB columns.

Related errors

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