apache/shardingsphere · error · SQLFeatureNotSupportedException

getParameterTypeName

Error message

getParameterTypeName

What it means

SQLFeatureNotSupportedException thrown by AbstractUnsupportedOperationParameterMetaData.getParameterTypeName(int). Without a backend PREPARE the ShardingSphere driver cannot resolve the SQL type name ('INTEGER', 'VARCHAR', ...) of a '?' placeholder, so the final method always throws; only getParameterCount() is supported.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationParameterMetaData.java:58

    
    @Override
    public final int getPrecision(final int parameter) throws SQLException {
        throw new SQLFeatureNotSupportedException("getPrecision");
    }
    
    @Override
    public final int getScale(final int parameter) throws SQLException {
        throw new SQLFeatureNotSupportedException("getScale");
    }
    
    @Override
    public final int getParameterType(final int parameter) throws SQLException {
        throw new SQLFeatureNotSupportedException("getParameterType");
    }
    
    @Override
    public final String getParameterTypeName(final int parameter) throws SQLException {
        throw new SQLFeatureNotSupportedException("getParameterTypeName");
    }
    
    @Override
    public final String getParameterClassName(final int parameter) throws SQLException {
        throw new SQLFeatureNotSupportedException("getParameterClassName");
    }
    
    @Override
    public final int getParameterMode(final int parameter) throws SQLException {
        throw new SQLFeatureNotSupportedException("getParameterMode");
    }
}

View on GitHub (pinned to e952770a21)

Solutions

  1. Stop using ParameterMetaData for type-name introspection under ShardingSphere; hard-code the expected type from your mapping layer.
  2. Introspect DatabaseMetaData.getColumns on the underlying database when a real type name is required.
  3. Catch SQLFeatureNotSupportedException and degrade to a generic type handling path.

Example fix

// before
String typeName = pmd.getParameterTypeName(1);

// after
String typeName = "INTEGER"; // take from your column mapping, not ParameterMetaData
Defensive patterns

Strategy: try-catch

Validate before calling

if (conn.getMetaData().getDriverName().toLowerCase().contains("shardingsphere")) { typeName = expectedTypeFromMapping; } else { typeName = pmd.getParameterTypeName(1); }

Try / catch

try { typeName = pmd.getParameterTypeName(1); } catch (final SQLFeatureNotSupportedException e) { typeName = null; /* use mapping default */ }

Prevention

When it happens

Trigger: ps.getParameterMetaData().getParameterTypeName(i) on jdbc:shardingsphere:. Hit by SQL builders that render dialect-specific literals from parameter type names and by DB-compat test harnesses.

Common situations: Migration from PostgreSQL/Oracle drivers (which return type names) to sharding-jdbc; generic migration or introspection tooling run against the sharded datasource.

Related errors

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/55077bb367a7a941. Report an issue: GitHub.