prestodb/presto · error · SemanticException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

non-default precision not yet supported

What it means

CURRENT_TIME-family functions (current_date, current_time, etc.) accept an optional precision parameter, but the analyzer only supports the default precision. Any explicit non-null precision triggers this NOT_SUPPORTED SemanticException.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/sql/analyzer/ExpressionAnalyzer.java:459

                // Note this is deliberately not getCanonicalValue(), which upper cases instead.
                Identifier identifier = name.get();
                String fieldName = identifier.isDelimited() ? identifier.getValue() : identifier.getValueLowerCase();
                // Duplicates are rejected because a row type with repeated field names cannot be
                // round-tripped through its TypeSignature, which the native worker relies on.
                if (!declaredNames.add(fieldName)) {
                    throw new SemanticException(DUPLICATE_COLUMN_NAME, node, "Duplicate field name '%s' in ROW", fieldName);
                }
                fields.add(RowType.field(fieldName, fieldType, identifier.isDelimited()));
            }

            return setExpressionType(node, RowType.from(fields.build()));
        }

        @Override
        protected Type visitCurrentTime(CurrentTime node, StackableAstVisitorContext<Context> context)
        {
            if (node.getPrecision() != null) {
                throw new SemanticException(NOT_SUPPORTED, node, "non-default precision not yet supported");
            }

            Type type;
            switch (node.getFunction()) {
                case DATE:
                    type = DATE;
                    break;
                case TIME:
                    type = TIME_WITH_TIME_ZONE;
                    break;
                case LOCALTIME:
                    type = TIME;
                    break;
                case TIMESTAMP:
                    type = TIMESTAMP_WITH_TIME_ZONE;
                    break;
                case LOCALTIMESTAMP:
                    type = TIMESTAMP;

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Remove the precision argument and use the function without parameters
  2. Round/truncate to the desired precision with a separate function like date_trunc or a cast to timestamp(6)
  3. Rewrite the query to avoid non-default precision

Example fix

// before
SELECT current_timestamp(6)
// after
SELECT CAST(current_timestamp AS TIMESTAMP(6))
Defensive patterns

Strategy: validation

Validate before calling

// reject precision args before sending SQL
Pattern p = Pattern.compile("(?i)current_(time(stamp)?|date)\\s*\\(");
if (p.matcher(sql).find()) throw new IllegalArgumentException("CURRENT_TIME precision not supported");

Try / catch

try {
    return execute(sql);
} catch (SemanticException e) {
    if (e.getCode() == NOT_SUPPORTED) {
        sql = stripCurrentTimePrecision(sql); // rewrite and retry once
        return execute(sql);
    } throw e;
}

Prevention

When it happens

Trigger: Calling current_time(3), current_timestamp(6), or any CurrentTime expression with getPrecision() != null.

Common situations: Migrating SQL from MySQL/Postgres where current_timestamp(6) is common, ORM-generated SQL that adds precision arguments, hand-porting vendor-specific datetime syntax.

Understand the failure class

Background: Presto NOT_SUPPORTED error: what "not supported" means and how to fix it — this error's family across 3 libraries.

Related errors

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